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The scope of this thesis is twofold. The first is to 
provide a nwethodolosgy for the yperformance measurement of 
datakase systems. The second is the apflication of this 
methcdclcgy to’a specific database system in an attempt to 
verify the applicakility Os this methodology and _ the 
performance and capacity claims of the database systen. 

As a treéthodology, the thesis describes the strategies 
and lecatiors for the placement of checkpoints, the kirds of 
perficrmance data to kre collected, the environment fcr the 
conduct cf the perfcrmance measurement and the interpreta- 
tion cf the results. One of the most impomutant Ccntrmege 
tions of this methodclogy is its Capability to obtain deta 
measurement overhead raking the presentation of truly accu- 
Tate results possible. AS an application of this métited= 
ology, we attempt tc validate the performance and capacity 
Claims cf an experimental muiti-backend database systen 
known as MDBS. Surprisingly, these claims have been 
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I. LNIRCDUCTION 


As A, THESIS OV ERVIos 


The scope 0f this Ghesiswis twocold. The first is@ae 
Frovide a méethodclogy to use in the performance measurement 
cf a cdatatase computer. The second is the applicaticn cf 
this methcdology to a specific database system and the 
attemrt tc verify the performance and capacity claims cf the 
target system. 

The database system Leing evaluated is an experimental 
multi-kackend database system known as MDBS. The Eacie 
design soal of MDBS is to develop an arcnitecture which 
spreads the work of the database management among multifle 
kackends. MDBS makes two Tasic claims in its design. The 
first is that by increasing the number of backends used as a 
part cf the datakase computer and by keeping the size cf the 
database ccnstant, the response time or the same trans- 
acticns iS properticrally decreased. Tne second claim is 
that ky increasing the number o£ backends and aiso 
increasing the size of the database, the respcnse time 
remains relatively ccnstant. 

To ccnduct the performance measurement of MDBS, various 
Ccheckrcints and data collections are incorporated intc the 
systen. Although all checkpcints and data collections are 
selected tc provide the greatest amount of useful infcraa- 
tion and to incur the least amount of overhead, scre cver- 
head is unavoidable. A quantitative method for measuring 
the overhead incurred is therefore provided. The periornue 
ance results of MDBS are then accurately adjusted using the 
overhead calculation. In this way, a truly accurate freas- 


urement cf the systen may be cktained. 


Peco Omi them ticsis describes the strategies 
and lccaticns of the checkpoint placement, the kinds of data 
en performarce ccllected, the ways in which the performarce 
measurement were conducted andthe interpretatior cr the 
results. Maybe of greatest importance is the ability to 
calculate actual measurement overhead allowing cor the fres- 
entation of truly accurate results. 

In this thesis, we will focus our attention cn the 
response tine of the work being done by the database system. 
we will net focus on the throughput. Whereas the threughrut 
is defined as the average numrfer of user reguests executed 
Ey the system in a second, the response time of a reguest is 
the time kEetween the initial issuance of the reguest bya 
user and tte final receipt of the entire response set of 
this reguest by the user [ Ref. 1]. Since the majerity of 
the reguests processed by a database system are reguests [cr 
the retrieval of infcrmation, another limitation is made to 
the sccpe of this thesis. We will focus on the performance 
measurement of the response time of retrieval reguests in 
MDBS. Forpefully, these evalvations will verify the claims 
cx MEBS and also frovide a general methodology fcr the 


performarce measurement of any database systen. 


Bees tRE ChGANIZATION CF THE THESIS 


This thesis is crganized into six additional charters 
beyond this overview. Chapter II describes our perfcrmance 
measurement methcdolccy for database systems. eee ede ey, 
discusses the need fcr such a methodology and continues with 
a se€parate discussicn of roth the internal and external 
perfcrmance measurements. The chapter then culminates with 
a discussion of the ccmbination of the two performance meas- 
urements, thus providing the methodology to calculate and 


adjust fcr internal ferformance measurement overhead. 


Chapter III presents an cverview of the target systen, 
MDBS, used to aprfly the performance measurement methcdclosy. 
A general discussion is given on the attrikute-Lased data 
model, the directory tables, the process structure, the 
message types, and tke execution of a retrieve reguest. 

The application cf the performance measurement methcd- 
clogy tc the target systen, MDBS, is presented in Chapter 
TVs The ceguired mcedifications to the MDBS software needed 
to perficrm the measurements iS discussed, along witha 
discussicn of the modifications to the test envircrment 
required to control the measurement results. A descriftion 
cr the additional software used ror both inter-coaputer and 
inter-frecess message processing measurements 1s also 
Provided. 

Chapter V presents the ccnstruction of the test database 


and tre selection of the reguests used in the performratnce 


measurements. In this chapter, the design of the desired 
test datakase 41s first discussed. Due to system 
constraints, only a subset of this design 1s used for 


testing furroses. Tre chapter concludes with an analysis of 
the reguests used in the performance measurement. 

All the thesis werk is Erought together in Charter VI 
with the presentation of the performance measurement 
results. Since the goals cf this thesis are to verify the 
perficrmance and capacity claims of MDBS andto frovide a 
methcdclogy for the fperfortance measurement of a database 
syster, only the tests needed to obtain these gcals are 
performed. In the chapter, results are provided for the 
external and internal performance measurements, and _ the 
results cf the message processing meaSurements. 

The thesis ends with conclusions in Chapter VII which 
can be made from the results. It provides a Summaticn for 
the entire thesis and offers suggestions in future werk 


which needs to be dcne both with the methodology and with 
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the measurement cf MIES. It is hoped that this thesis will 
Frovide a scund gethcdology ror the performance measurements 
cf datakase systems ard alsc provide a definitive verifica- 


fmeonm cr the perfcrmarce and capacity claims of MDBS. 


II. FERFORMANCE MEASUREMENT METHODOLOGY FOR DATABASE 


SISTEMS 


In this charter, we present a performance measurement 
methodclcgy for datalase systems. The methodology requires 
the ccllection cf Ecth internal and external pericriamee 
measurements. The internal performance measurement nethod- 
Ology is the collection of methods and tools which wall 
enacle a ketter understanding of the target system [Ey meas- 
ULINgG Celtain Gapabliitics Ory thaeeoyoteue In measuring 
certain capabilities cf the system, we focus on the measure- 
ment cf tine Spent in individual processes of the target 
syster. The external performance measurement methodclcscy is 
the ccllection cf methods and tools which will enable the 
ketter understanding cf the target system by measuring the 
system as a whole. In measuring the system as a whole, we 
focus cn the measurement of the response time of the target 
systen. The response time in a database system is defined 
in [Ref. 1] as the time between the initial issuance of the . 
request Ey a user andthe final receipt of the entire 
respcnse set of this request Ly the user. 

In the rest cf this charter, we begin by examining the 
need for adatabase system and the subseguent need to 
measure the perfcrmance of the systen. We then discuss a 
general ferformance reasurement methodology, addressing bcth 
internal and external perfcrmance measurement as separate 
issues. Finally, we conclude the chapter with a discussion 
of the ccmkination cf internal and external performance 


measurement results tc provide a complete methodolcgy. 
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Rome LEE NEEL 


The need for a catabase can best be shown as ccrre- 
eeending tc the need for infcrmation. A database is a 
repository for the stcrage of information on a computer, any 
item cr comktination cf items of which can te easily accessed 
in a relatively short timeframe. A businessman may desire 
all the latest pieces of information to make’ a management 
decision. The combat field commander may desire complete, 
up-to-the-minute repcerts to arrive at a tactical decisicn. 

Put there are ferformance and capacity problems that 
must ke cvercome in j;roviding this information. AS an ever 
increasing amount of information is stored in a datatkase, 
the respense time of the datakase system increases notice- 
EOE Y In addition te the increase in the size of the data- 
kase, tkere is the effect cf increasing the number cf users 
accessing the system and the number of reguests tc be 
Frocessed Ey the systen. Thus the user must seiect Lletween 
the respense time desired and tne information desired, a 
choice tke user does not want to and should not have to 
make. The database system needs to be easily upgraded to 
accommocate new users and to increase the database size 
without noticeable change in response time. This is the 
need for the response-time invariance ina database system. 

Anctker problem -is in the timeliness of a response. the 
datakase system should offer a dependable, constant return 
rate fcr the response to a reguest. When response time 
kecomes unreasonably long due to the computer workload, the 
user will te frustrated. A user desires to have every 
request returned in a timely manner. This is the need for 
Tesponse-tine Consistency in a database systen. 

A firal problem is to insure that all necessary infcrma- 
tion is available to the user. Incomplete informaticn is of 


little use. For example, a user may reguire all reguests to 


ey 


have a regpcnse within a specified timeframe. This regquire- 
ment cften dictates the maximum size of the database anc the 
Maximug rugter cf reguests. Therefore, axr undesirearkle 
limitaticn is placed cn the amcunt of information avaliaere 
due te tke limitaticn on datakase size. Again, the user is 
forced into making a tradeoff between the response tize and 
the availakle inforgation. Nevertheless, despite the 
respcnse time, such anformation should be made available to 
the user on demand. This is the need for availability of 
inforraticn in the database systen. 

Therefore, not cnly is there aneed for a database 
system, there ie vale cram eed lt ciama cies sales system with the 
gualities cf Invariance, Consistency, and Availarility 
(ICA). Eut ICA can fe present in varying degrees ina data- 
bkase systen. The degree of ICA can best ke demonstrated by 
the perfcrmance measurement of the database systen. 

There are two basic types of database systems. The 
first is an online scftware database management system that 
runs cn the host comfputer systen. The second 1s a database 
machine, which offlcads the database functions tc a dedi- 
cated Eackend ccmputer. The current trends in datakase 
systems invelve the design, inplementation, and use cf data- 
base machines [Ref. 1 through 8]. Net only 1s there an 
apparent improvement in ICA with a corresponding rice fer 
Ferfcrmance advaatage, but a database machine can free up 
resources at the host, provide support for multiple, dissin- 
ilar hosts, and increase the security on the database by the 
Physical separation cf the datakase and the host. Cue 
primarily tc the trerd toward increasing future use cf data- 
kase tachines, this thesis will concentrate on the discus- 
Sion and application of the methodology for measuring the 
datakase Machines. 

A database machine 1s a database system composed cf cne 


Or more precesscrs, dedicated to performing the database 
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Management functions. feromindis putable that a datakase 
Eachine is the ketter of the two types of database systems 
With regards to froviding an increase in security, allcwing 
mee guUltiple host support, and freeing up the hest 
resources. But there still exists the need to demcnstrate 
an improvement in the ICA on a database machine over the ICA 
BPeevideaq -ty a hest-resident database systen. At the sane 
time, there exists a need to ccmpare the invariance, consis- 
tency and availability cf several different database 
Tachines and software systems. Ayain, this can best be 
demonstrated by meastreing these systems. 

kégpense-time consistency is more easily achieved ira 
datakase machine thar ina database system running cn the 
host. Whereas the host must Share its resources witk a 
Varying werkioad, the kackend can dedicate its resources for 
datakase management. Availability frees the TLatabase 
Administratcr from the necessity to make tradeoffs Ltetween 
the size of the datatase and the response time. The adminis- 
tratcr can then load the database with all the necessary 
information regardless of the database size. To achieve and 
verify tke response time invariance. of a database machine, 
a methodology to measure its effectiveness must be 
develcped. 

Thus, the scope cf this thesis is to provide a yerforn- 
ance feasurement methodology fer database machines and to 
verify this methcdolcgy by verifying the design claims of a 
specific database machine, known as MDBS. Again, these 
claims are related tc the guality of response time invari- 
ance; that is, te be akle to change tne size of the database 
and at tke same time maintain constant response tim@e cr to 
hold constant the size of the database with the ability to 
reduce the response time. Consequently, the measurement of 
the respcnse time of a database system becomes the focal 


FOint cf our studies. If the response time can be frerferly 
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and accurately measured, the claims of the target system can 
ke verified. Furthermore, the erfectiveness of the methcd- 
clogy can also te verified. A proper measurement cf the 
response time can frcevide a FEaseline measurement to which 
cther database systems can be compared and thus prcvide a 
price-performancée ccaparison of various systems. This 
thesis frevides an overhead-£ree performance-measurement 
methcdolcgy and apflies this methodology to verify the 


clains of an experimertal datakase machine. 


Be. TEE APPROACH 


In this section, we discuss a general nethodology to be 
used in the performance measurement of a database systen. 
This méthodclogy is ceneral and can be applied to any cttker 
dataktase systen. We first discuss the internal performance 
measurement. This ircludes the design considerations, the 
software engineering criteria andthe applicaticn of the 
methcdolcgy to a particular systen. Then we present a 
discussicn of the external performance measurement, again 
discussing the design considerations, the software engli- 
neering criteria, and the application of the methcdology to. 


a particular systen. 


1. A Methodology for Internal Perrormance Measureremm 


The goal of the internal performance measurement 
methcdolcgy is to frovide methods and tools which will 
enable us to better understand the target system [y meas- 
uring certain aspects of that systen. A complete under- 
standing of how the system performs internally may lead to 
design mcdifications cr to fine-tuning of the system for 
retter performance. The internal performance measurement 
tools shculd be unoktrusive to the user, available wken 


necessary, yet out of the way when not reguired. They should 
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re integrated with the target system to produce a szrooth 
transiticn kLetween target system operation and the oferation 
Seeche tcol. In the first part of this section, we address 
the design considerations cf internal performance measure- 
ment methods. Next, we discuss certain software engineering 
criteria which are afrlicable to the design of good measure- 
Pomeecocis., Finally, we explore the applicaticn cf the 
internal performance measurement methodology to a particular 


systetr. 
a. DeSign Ccnsideraticns 


Internal performance measurement relies or 
checkreints internal to the database system software. A 
checkrpeint is defined as a procedural invocation inserted 
into the system's ficw of control to call the performance 
measurement routines which are used for the data collecticn. 
Syste overhead is introduced as each checkpoint is added to 
the target system. Additionally, measurement software is 
required tc process tke checkpcint data in a manner conmpat- 
ible with the existing target system software. That is, a 
certain pertion of the measurement - software must Le inte- 
grated with the target system software to handle events such 
as data storage, message passing, and information frecessing 
that relate to the ckeckpoint data. Finally, the existing 
target system software may require additional lines of code 
to handle new cases introduced by the measurement systen. 

In mcst external performance measurement, cver- 
head is negligible. However, internal measurement routines 
add significant cverkead to the database system which cannot 
ke disrecarded. For internal measurement, we must discover 
ways to reduce the cverhead generated by the measurement 
software. We must also kre able to measure the cverhead 
which cannct be elimirated, sco that the measurements can be 


adjusted accordingly. A very important reguirement is that 
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the existing target ‘system Gust Maintain the capability of 
running unimpeded by tke additional measurement software. 

Consideration must be jiven to the level in the 
target system where checkpoints may be flaced. Some fossitle 
levels are at the very high level, i.e., the syster level, 
the high level, i.e., the program level, the medium level, 
lee., the subroutine level, andthe low level, i.eé€., the 
subroutine segment level. Whereas external performance 
measurement only places checkrcints at the very high level, 
internal fperformance measurement places checkpoints’ frelow 
that level. Checkpcints must Fe placed ata level which 
Froduces data in sufficient detail to provide the user with 
a basic understandine cf the system's performance character- 
SECS. Checkpoints should not be placed at a level sc low 
as to overwhelm the tser with detailed data or to interitere 
Significantly with system performance. 

For internal performance measurement, the user 
should have the capakility to access selected data cut of a 
range cf possible chcices. The user should not be reguired 
to receive informaticn about processes which are net of 
current interest. Tke interface should be easy to use and 
Should net distract tke user f£rcem his primary goal of under- 
standing the database system by reyuiring the user to 
remember the unigue syntax or semantics or the test inter- 
face. Tke collected reasurements should be made accessitfle 


to autcmated processing routines for data reduction. 
rk. Software Engineering Criteria 


Measurement software should be designed using 
modern scftware engineering metnods. The resulting software 
Should be understandakle, maintainable, reliatle and compat- 
ible with the target systen. Certain software engineering 
methcds are of particular interest. These methods are rodu- 
larizaticn, user-friendliness, data abstraction, and 


Sim eireiwty . 


For modularity, the measurement programs should 
ke hierarchically structured with well-defined interfaces. 
The measurement modules should Le reusable througkout the 
target systen. Modularity allcws the system to be easily 
extended to checkpoints not considered in the initial sjpeéeci- 
ficaticns. The test interface should present an easy-to-use 
method for obtaining test data. Pero tOouldes automatically 
aggregate data while still allowing the user to access raw 
data. The user should not have to remember the specific 
syntax and semantics cf the test interface. Delieel ies) ecke— 
tion shotld be used sc that sukseguent program modificaticns 
do net restlt in extensive reprogramming. Aiea eprOpriate 
choice cf primitives ( data structure and operations ) will 
allow for easy change and produce less system overhead. fthe 
weasurement system shculd be user-friendly. Piero ttre Lo 
cbheying the simplicity ;rinciple, the test interface stould 
ke forgiving, i1.e., system should not crash on bad input, 
Frovide readable errcr diagnostics, anticipate errors, and 


guard against thcse errors. 
e-issucs 420 the Application to Database Systems 


MOoicat ren or the internal perrormance measure- 
ment wethodclogy to a particular database system requires 
that the evaluator understand certain aspects of the target 
systen. Tke evaluator must understand the programming 
lanyuage used to ccnstruct the database system, and _ the 
structure and operaticn of the database systen. The evalu- 
ator must ke prepared to overcome obstacles presented Ey the 
target system in the course of the implementaticn cf the 
perfcrmance measurement. 

A thorough understanding of the programming 
language is necessary to successfully integrate checkfcints 
and data ccllecticn programs into the existing software 


structure. One must be familiar with the data structures, 


COhepel Structures, naming conventions, and fparameter- 
passing mechanisms of the language, in order to iapiement 
the measurement programs efficiently and to minimize their 
overhead. Knowledge cf the language syntax reduces progran- 
Ming errors and speeds implementation of the measurement 
tools. 

For effective internal performance measuremrenrt, 
checkrcirts must be ccrrectly flaced in the database system. 
Incorrectly placed ckeckpoints increase overhead and degrade 
rerfcrrance measurement by providing useless data te the 
user. The evaluator must possess sufficient knowledge cf the 
target system to alicw for the correct placement of check- 
points. This provides the srocth integration of data collec- 
tion LECQEatc, data processing programs and data trarsfer 
Frogrars into the existing database systen. 

Chances are that the target systen, when 
initially designed, was not designed with internal ferfora- 
ance measurement in mind. Instead, the target syster was 
designed te process all Treguests efficiently. Integration 
of the internal rperformance measurement routines may affect 
the target system ir unexpected ways. Let us consider two 
examples cf such ways. First, in a meSSage-passing systen, 
messages generated [ry the measurement programs may reéguire 
modifications to the existing database system so that test 
messages will not be confused with the messages of the data- 
rkase system. Second, the volume of information generated by 
the measurement programs may overload selected secticns of 
the target systetm. The evaluatcr of the performance meas- 
urement routines must be prepared for such contingencies. 
Py using the kncewledge of the programming language alcng 
with the knowledge cf the database systen, the evaluator 
gust Le prepared to cffer sclutions to the database adminis- 
trator cn hew to gracefully integrate the performance meas- 
urement mechanisms into the target system with [roger 
modification and withcut overlcad. 
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2. A Methodology for External Performance Measurement 


The goal of external ferformance neasurement is to 
Frovide a ccllection cf methods and tools wnhich will enatle 
us to Fetter understand the target system by measuring the 
system as a whole. In this way we can measure the total 
work reirg done Ly tke datakase systen. We focus cn meas- 
uring the response time of the systen, the elapsed time 
ketween the issuance of a reguest and the receirt cf the 
respcnse tc the reguest. 

Internal performance measurement has been shecwn to 
ke beneficial in the fine-tuning of a system, and in the 
Ticrcsccpic examinaticn of the work peing performed fy the 
system. External measurement frovides a guantitative meas- 
urement cf the system from a macroscopic view. Poco Loews 
for the ccupfarison of database systems. In the first part 
cf the section, we discuss the design considéeraticns of the 
external performance freasurement methods. Next, we present 
the software engineering criteria for external performance 
measurement. tastly, we Show the application of the 


external performance geasurement to a system. 
a. Design Ccnsiderations 


External performance measurement should have 
nejgligicle overhead, i.e., the response time with external 


performance measurement should be the same as the resfonse 


time without measurement Leing performed. Lise S sin, fact 
the case. The reascn tnat the overhead is negligible is 
that cnly two timing checkpoints need to be made. These 


timing checkpoints are placed at the beginning of a recguest 
and the end of the response tc the request, thus providing 
the elapsed time of the resfonse for a reéeguest. The timing 
checkrpcints need the system tire at the start and comrpletion 


cf the reguest. The checkpoints are placed at the very high 


Ze 


level to insure a complete measurement or the total elapsed 
time. 

There are other issues that must be consicered 
to insure that the system being evaluated is as ‘Lure’ as 
fossifle. First, the system should retain only thcse ccde 
and messages reguired for the running of the systen. 
Messaces and code incorporated into the system for the 
design cr debugging of the system should be remcved. 
Second, the system should not contain unnecessary software 
tools designed to aid the measurement, such as those used to 
create a test database. Such tools should remain in soft- 
ware exterioc to the actual database systen. 

An obvious consideration is to insure that no 
human interaction is involved in the timings. The systen 
software, not the reaction time of the user, is beinc timed. 
Therefore, the timer should start immediately after a user 
releases the reguest. The timer should stop immediately 
Frior to tte display on the selected output device. The 
reascn fcr stopping tke timer prior to display is due tec the 
varying delays caused by the output devices. The speed of 
an cutput device shculd not be included” into the  Sysru 
tinine results: 

The final issue involving the placement of 
external performance measurement checkpoints 1S whether to 
embed tke timer code in the system or to call a timer 
routine outside the system. A call to a timer rcutine 
ancurs unwanted timing delays, adding to the impurity of a 
systen. Iz the timer code is embedded, it can te made to 
appear tkat the systexz code being tested is embedded in the 
timer ccde, i.e., placing the timer initialization cede just 
prior to the point of the request by the user and the timer 
finalization code jrst subsequent to the display cn the 
Cutput device. With these considerations, an optimal fplace- 
tent of ckeckpcints can be selected to take exterral 


perfcrmarce timings. 


26 


rk. Software Engineering Criteria 


Unlike internal performance-measurement software 
which uses software design mrethodologies, the exteriral 
perficrmance-measurement software uses software design tcols. 
inert. 9)], a Lull description is provided of the necessary 
external performance-reasurement tools. These tools include 
a test-file generaticr package, a database load sulksysten, 
and a reguest generation package. 

The ~urpcse of the test-file generation package 
is tc create a test database. This ailows for the easy 
creaticn of a database containing the desired parameters to 
ke evaluated. The database load subsystem must frejerly 
load the files created in the generation package. This 
includes the creation of directories for the test datakase. 
The reguest generaticn package is used to create and execute 
test requests, and frovides fcr easy variance in the tyres 
and ccaplexity of requests. This package also archives the 
requests for later tse. Using these tools, the external 
perfcrmance timings of the database system under measurement 


can ke easily obtained. 
ce. Issues in the Application of the Methodology 


The ease with which external performance meas- 
uremert can be perfcrmed on a database system can vary. 
There are two important considerations: the languace in 
which tke system is written and the degree of software engi- 
neering used in the database system design. 

The language needs to be readable and to cecmpli- 
ment frorer documentation of the system. Dias we dt faci li= 
tate an understandin¢e cf the system by the system evaluatcr. 
The language must alsc be powerful enough to easily inccrpyo- 
rate system commands, such as requests for the system tine. 


A language, such asC, has these capabilities, keing 
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primarily designed fcr system projramming. C 1s a hagbe 
level language, Hey Gamelan: roth powerful and portable. 
Althcugh the support software tools such as datakase lead 
can Le inuplemented ina language other than the language in 
wnich tke database system was written, the evaiuatcr needs 
to ke familiar with several different languages if several 
different database systems are to be evaluated. 

The degree of software engineering used in the 
datakase system design will most definitely facilitate any 
external performance measurement to be done. if the Gamean 
kase system was hierarchically designed using moduiarity, 
knowledge cf the internal workinjs of the system ry the 
evaluator will be minimal. Only the upper level in the 
hierarchy need to be studied for the proper placement of the 
checkpc iats. External measurement only reguires a _ t&acro 
knowledge of the systen. This is to insure that the check- 


points are indeed prcperiy flaced at the very high level. 


C. TEE COMBINATION CF INTERNAL AND EXTERNAL PERFORMANCE 
MEASUREMENTS 


Separately, internal and external performance measutre- 
ments provide a weaith of infcrmation to the evaluator. 
Internal ferformance measurement provides the timings and 
data ccllections of individual processes inthe database 
systen. External performance measurement provides the 
elanpsed time for the complete request. Yet, when the two 
methcdclcgies are comkined, there is a synergistic efrect to 
the amcunt cf information available to the evaluator. 

The ccmbination cf internal and external performance 
measurements is natural. There are benefits to [ce gained 
for one freer the other. For example, we can determine the 
overhead incurred wken using internal performance measure- 


ment; first, using the external checkpoint, we collect the 
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elapsed time for processing a farticular reguest. This time 
is then ccmpared to the elapsed time of the reguest wen 
Eoth irternal and external checkpoints are enabled. The 
difference in the elapsed times of these two measurerents 
Frovides an exact measurement of the overhead incurred by 
the airternal performance measurement software for tais 
reguest. 

Cn tke cther hand, we can use the internal perfcrmance 
Measurement timings to interpret the external performance 
measurement timings. In particular, if a rejuest takes many 


hundredtrks cf a seccnd as a result of external performance 


measurenent, the evaluator wouid want to determine the 
precise distribution of the work. Internal performance 
measurement can answer these guestions. By combining the 


twO measuretents, tte whole of the measurement results 1S 
More meaningful and useful than the individual results. 

in the following chapter, the target system, i.e., #«ALBS 
is described. This is the system selected to be evaluated 
using tke internal and external performance measurement 


methcdolcgies presented in this chapter. 
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THE BULTI-BACKEND DATABASE SYSTEM (HDBS) 


ae 


In this chapter we discuss the configuration and theory 
cf opeéeraticn of the multi-rackend database system (MIBS). 
This chapter has been extracted from papers and rerorts 
‘which have keen written on MDBS [Ref. 6, 10, 11, 12). 

MIES uses twe or more identical mMinicomputers and theic 
disk systems to provide a centralized database system with 
Support for multiple, dissimilar hosts. One minicomputec 
functicns as the controller. User access is acconrflisked 
througk a host computer which in turn communicates with the 
Gemerclhver: Multiple minicomputers and their disks are 
configured in paraliel to serve as backends. The criginai 
design and analysis cf MDBS is due to J. Menon [Ref. 1, 2]. 
The infplementation and new design efforts are documented in 
[Ref. 3 thrcugh 6}. The datakase is distributed acrcss all 
cf the kackends. The dataktase management functicns are 
replicated in each backend. 

As shown in Figure 4.1, the controller and the ktackends 
are ccnnected by a k-roadcast bus. When a transacticr is 
received frcem the host computer, the controller breadcasts 
tne transaction to all the Lackends. Each backend has a 
number of dedicated disk drives. Since the data is distrib-— 
uted acress the tackends, a transaction can be executed by 
all backends concurrently. Each kackend maintains a queue of 
transactions and sckedules reguests for execution inde—- 
pendent cf the other backends, in order to maxinize its 
access cpérations and to Minimize its idle time. The 
contrclier does very little work. It 1s resporsikie for 
kroadcasting, routing, and assisting in the inserticr cf nhew 
data. The backends do mcst of the database operations. 
Fresently, MDBS is fully operational with a VAX 11/7780 as 
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The MDBS Structure. 
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tne ccentrcller and tno PDF 11//44s and their diske as the 
kackends. 

MIBS is a mesSage¢e-oriented system. In a nessage—crientec 
system, each process corresponds to one system functicn. 
These processes, then, communicate among themselves by 
Fassirg tessages. User reguests are passed Letween fErecesses 
as messaces. The message paths between processes are fixed 
for the system. The MDBS processes are created at systen 
Start tine and exist until the system is stopped. 

MCBS is designed to perform the primary database cpera— 
tions, INSERT, DELETE, UPDATE, and RETRIEVE. Of these lame 
datakase operations, cnly the retrieval operation will [|e or 
concern to ws in this thesis. The syntax and semantics of 
the retrieve operaticn is discussed in Charter V. Users 
access MLPEBS through the host by assuing either a reguest or 
a transaction. A transacticn is a set of requests. A 
gualificaticn is used to specify the informaticn of the 
Catatase ttat is tc be accessed by the reguest. Mcre 
complete definitions cf the MCPES terminology can be found in 
the fcllcwing section. 

In the remainder of this chapter we first discuss the 
directory structure. Next, we provide an overview cf the 
Frocess structure. Then, a presentation of the message tyres 
is Erevided- Lastly, we trace the execution sequence of a 


retrieve request. 


A. TEE ATTRIBOTE-BASED DATA MCDEL 


In this section we discuss the attripute—based data 
model. Next we provide some definitions in order to discuss 
MDBS directcry data. We conclude this section by describing 
the tables necessary to maintain the MDBS diréctcm, 


INEOL Tastac pe 


a 


In the attrikute-rased data model, data is modeled with 
the ccnstructs: datatkase, file, record, attribute-value 
Fair, directory keywerd, directory, record body, keyword 
predicate, and guery. Informally, a database consists ofa 
@or1ecticn ci files. Baicwert le Contains groups ci records 
which are characterized Ey a uniygue set of directcry 
keywords. A record is composed of two parts. The first 
part is a collection of attribute-value pairs or keywerds. 
An attrikutevalve pair is a member of the Cartesian preduct 
cf tke attribute rame ard tne value domain of the 
attribute. As an e€xample, <POPULATION, 25000> is an 
attrikbute-value pair having 25000 as the value for the foru- 
Beeon attribute. A record contains at most one attrikute- 
value fair for each attribute defined in the datatase. 
Certain attribute-value pairs of a record (or a file) are 
called tite directory keywords of the record (file), because 
either the attribute-value fairs or their attrikute-vaiue 
ranges are kept in the directory for addressing the reccrd 
eraiec). Those attrikute-value pairs which are net kerft in 
the directory for addressing the record (file) are called 
non—directcry keywords. The rest of the record is textual 
informaticn, which is referred to as the record kody. An 


éxample cf a record is shown Lelow. 


Mmecegit, Census>, <CITY, Wonterey>, <POPULATION, 25000>, 


{ Temperate climate } ) 


The angle Erackets, <,>, enclose an attribute—value fair, 


i4-e., keyword. The curly brackets, {,}, include the record 


Ody « The first attribute-~value pair of all records of a 
file is the same. iMeogib@telildnm,ethe attribute 1s FILE and 
the value is the file name. A record is enclosed in the 
parenthesis. For example, the above sample record is fron 


the Census file. 
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The database is accessed by indexing on directcry 
keywords using keyword predicates. A keyword predicate is a 
three—-turple consisting of an attribute, a relational cper— 
ator (=, #, 24 Se 764 SS), and an attribute valuc, ince 
FOPULATICN 2 20000 is a keyword predicate. More specifi- 
Gd, et od grea ter—than—or-—egual—to predicate. 
Combinince keyword redicates in disjunctive normal fcrnm 


characterizes a guery of the datakase. The query 


( FILE = Census and CITY 
( FILE = Cérsus and CITY = San Jose ) 


Monterey ) or 


will be satisfied by all records of the Census file with the 
CITY cf e€ithker Monterey or San Jose. For clarity, we auee 
employ parentheses fcr bracketing predicates ina guery. 
Recall that in MIBS there are four types of reguests 
waich ccrrespond to the four frimary database operations. An 


example cf a retrieve reguest would be: 
RETRIEVE { FILE = Census and POPULATION > 109010 ) (Cia 


which retrieves the rames of all those cities in the Census 
file whcse population is greater than 10000. Notice tkat 
the qualification cciponent of a retrieve request Cconstor. 
of twe farts, the guery of two predicates ( FILE = Census 
and PCPUILATION > 1000C ) and) the targes tis eerie The 
guery specifies which records orf the database are tc be 
retrieved. The target list specifies the attribute—value(s) 
to be returned to the user. A user may wish to treat two or 
more requests aS a transaction. In this situaticn, MDBS 
executes the reguests of a transaction without permuting 
them, 1.€., if T is a transaction containing the fequc ce. 
<RI>D<E2>, then MDBS executes the reguest R1 before reguest 
RZ. Firally, we define the term traffic-—unit to represent 


€ither a single Lreguest or a transaction in execution. 
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bee LEE DIRECTORY TAELES 


femldgadgesthe database (oOrten rerered to as user data), 
MDBS uses directory data. Directory data in MDBS corresfonds 
to attrikutes, descriftors, and clusters. An attribute is 
used to represent a cateyory of tne user data; euige, 
FOPULATICN is an attribute that corresponds to actual foru- 
itie~ens stored in tke database. A descriptor 1S used to 
Meeeribe a tange of values that an attribute can have; €.g, 
mroro0 1 Ss POPULATION <¢ 15000) is a possible descrirtcr for 
the attribute POPULATION. The descriptors that are defined 
Mepean attribute, ¢€.9., population ranges, are mutually 
exclusive. Now the notion of a cluster can be defined. A 
cluster 1S a group of records such that every record in the 
cluster satisfies the same set of descriptors. For example, 
all records with POPULATION rEetween 10001 and 15000 nay cern 
one cluster whose descrirtor is the one given above. In this 
case, tke cluster satisfies the set of a single descriftcr. 
In reality, a cluster tends to Satisfy a set of mulitirle 
descriptcrs. 

Cirectcry information is stored in three tatles: the 
Attrikute Table (AT), the Descriptor—to—Descriptor-—-Id Tatle 
(DDIT) and the Cluster—Definition Table (CDI). The Attribute 


Table maps directory attributes to the descriptors derined 
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Figure 4.2 An Attribute Table (AT). 


A sample AT is depicted =n f2qurews- The 


cn then. 

lesctiptcr-to-Descriftor-id Table maps each deseri; tor cm 
unigue descriptor id. A sample DDIT 1S given in Figure 4.3. 
Note that the pointer shown in Figure 4.3 is not actually in 


the DLIT takle but is Shown here for clarity to relate back 
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Descriptor ad | 

fe C < POPULATION $ 50000 | D11 ! 

50001 < POPULATION < 100000 | az 
| 100001 < POPULATION < 250000 | Dales | 
| ~ 250001 S POPULATEON @= 500000 j D114 
C-—> CITY = Cumberland | D21 { { 
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! CITY = Coluntus | D22 | 
F—> FILE = Employee { D31 | 

| C FILE = Census | Daa { 
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Figure 4.3 A Descriptor—to-—Descriptor—Id Table (LDI1). 


to the AT table cf Figure 4.2. The Cluster—Definition Taki 


D 





maps descriftor—id sets to cluster ids. Each entry consists 
cx tke unigue cluster id, the set of descriptor ids whose 
descriftcrs define the cluster, and the addresses cf the 
records in the clusters. A sample CDT is Shown in Figure 
4.4. Thus, to access the directory data, we must access the 
Al, CLEL pj wcand. Ghai. 

Cne cf the key concepts used when designing the test 
dGatatase (See Chapter V.) is defining the descriptors which 
are specified in the directory attributes. Thus, we previde 
a brick introdue lene co the three classificaticns of 


descrifrtecrs. A type-A descriptor 1S a conjuncticn cia 


3€ 














a ae a =o 
Teg Desc-—Id Set hdiaie | 

eee meer (aar ! 

| C2 fo, P22,032 A3 ae 
| 

ne | 


= 
| 
| 
| 
| 


Figure 4.4 ApGlticeer-letintton fable (CDT). 


less-than—or-egqual—tc predicate and a jreater—than-—or-—ecsual— 
to predicate, such that the same attribute appears in both 
predicates. An example o£ a type-A descriptor is as 
@olicws; 


((ECEULATION > 10000) and (POPULATION < 15000)). 


A type—B descriptor ccnsists cf only an equality predicate. 


An example cf a type-E descriftor is: 
(FILE = Census). 


Finally, a type—C descriptor consists of the name cf an 
@ttrikute. The type-C attribute defines a set of typeC 
sub—descriptors. Type-C suk-descriytors are equality fredi- 
cates defined over all unigue attribute values which exist 
in the database. fFcr example, the type-C attribute CITY 


forms the type-C sub-descriftors 
(CLTY=Cumberland), (CITY=Columbus) 
where "Cumberland" and "Columbus" are the only unigue data-— 
Fase values for the CITY. 
oe LEE ERCCESS STRUCTURE 


Currently, MDBS does not communicate with a host 


machine. The absence cf this communication reguires that the 
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Figure 4.5 The MDBS Process Structure. 
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test interface process, the process used to interact with 
mobs, ce glaced in the MDBS Ccntroller. fhe current impie— 
mentation cf MDBS doé€s not utilize a vproadcast bus. Instead, 
MDBS utilizes farallel ccmmunications jlinks (PCIs) to 
emulate a broadcast fus. Foth the controller and the kLack-— 
ends ccntair processes to interface with the PCLs for inter-— 
computer message passing. These processes, while necessary 
Bomintecrtace With tke PCLS, are not part of MDBS and will 
not Ee discussed further. Figure 4.5 provides an cvérview 


crt the MIBS Precess Structure. 


Ic EROCESSES Cemthe Cent roller 


The controlier 1S composed of three fErecesses: 
Reguest Erefaration, Insert Information Generation, and Pcst 
Processirg. Request Preparation receives, parses and 
formats a request (transaction) Fefore sending the fcrmatted 
request (transaction) to the Directory Management prccess in 
each kackend. Insert Information Generation is used _ to 
provide additional information to the tLackends when an 
insert reguest is received. Since the data is distributed, 
the insert cnly cccurs at one of the backends. Thus it must 
determine tke backend at which the insert will occur, alcng 
with the cluster and descriptcr ids for the insert. Post 
Frocessing is used te coilect all the results of a recsuest 
(transaction) and fcrward the information back to the host 


computer. 


Peele morocesses CE Each EFackend 


Fach backend is alse composed of three preccesses. 
They are of course different from the controller ;rocessées. 
They are: Directory Management, Copcurmency Contrcl, and 
Record Processing. Directory Management performs Descriptor 
search, Cluster Search, and Address Generation. Descriptor 


Searck determines the descriptor ids that are needed fora 


3S 


reguest. Cluster Search finds the cluster ids. Address 
Generaticn determines the secondary storage addresses neces— 
Sary to access the clustered records. Concurrency Contrce 
determines when the reguest can be executed. Reccrd 


Processing ferforms the operaticn specified by the reguest. 


Dow TEE BDES AESSAGEST EES 


In this section we describe the MDBS message-passing 
facilities first described ine i Rete ion In the ames 
message-fassing facilities there are 31 message tyres and 


che général message fcrmat (shown in Figure 4.6). This same 


Message Tyre (a numeric code). 
Message Sender (a numeric code). 


Message Receiver (a numeric code). 


Message Text (an alphanumeric field 
terminated by an end 
ci message marker). 


a | 
| 
| 
i 
| 
! 
| 
| 
! 
| 
| 


ee ee 
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Figure 4.6 The General Message Format. 


format is used for each of the three message passing facili- 
ties, namely, messages within the controller, messages 
withir a Lackend, and messages between computers. Messages 
ketween computers are divided into two classes, tessaces 
ketween Lackends, ard messages between the contrcller and 
the Ekackends. Figure 4.7 descrikes each of the MDBS message 


types. Figure 4.8 describes the abbreviations used. 
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Figure 4.7 
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Figure 4.8 MDBS Message Abbreviations. 


Ccmmunication between computers in MDBS is achieved by 
using a tinre—-divisicrmultiplexed bus called the farallel 
communication link (ECL) [Ref. 14]. MDBS contains a soft-— 
ware interface to this bus for each computer consisting of 
two cciplimentary prccesses. The first process, geét-pcil, 
gets messages from other computers off the PCL. The seccend 
Frocess, fut-pcl, futs messages on the bus to [ce sent to 
other ccgputers. The contrclier and each backend have their 
cwn gét—pcol and fut—fcl processes. 

In the remainder cf this section, we give short descrip— 
tions cf the definitions of MIBS messages. ‘These defiri- 


tions are of =f hevt ore 


(mneSsage-tyre number) message-type name: explanaticn of 


message. 


The descriptions will be given by the process that receives 
the message. These descriptions are in following figures: 
Reguest Freparation (Figure 4.9), Post Processing (Figure 
4.10), Directory Management (Figure 4.11), Record Processing 
(Figure 4.12), Coneurrency Cont rolye adie ss.,: 3a, Hest 
processed for Test Interface (Figure 4.14), and Insert 


Informaticn Generaticn (Figure 4.15). 


(1) Hest Traffic Unit : The traffic unit represents a 
See reyuest or transaction from a user at the 
hest machine. 





(12) Record that has Changed Cluster : This message is 
a record which has changed cluster, Request 
Freparation will prepare it as an insertion and 
send it to tke backends. 


| 

| (zS$) No More Generated Inserts : This message indicates 
that all the records that have changed cluster as 
a result of ar update request have been sent to 

kequest Preparation. 

| 


(14) Eesults of a Fetch or kKetrieve Caused by an Update: 
This message carries the information from a fetch 
cr retrieve frack to pass Preparation to complete 


an update with a type-lII or a type-IV modifier. 
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Figure 4.9 Request Freparation Messages. 
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| 
. ( 
(=) Numrer of Recuests in a Transaction : Reguest | 

Frefaration sends to Fest Processing the numter | 
Cf tequests in a traffic unit. This enables Fost 
Frocessing tc determine whether the processing cf 
Paeediite UNIt 15 come lete. 


€ aggregate operators to Post Processing. 


(5) Fequests with Errors ;: Reyyests with errors will 
ke found in féequest Preparation by the Parser ard 


Some tO Lost Ss osha fee: Poste Bocess lng 
e ac 


will send regtests wit bEOLrSs k to the host. 
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(11) Results cf a Fequest from a Backend : This message 
contains the results that a specific Ltackend fcund 
fcr a reguest. 


(1Z) Aggregate Operator kesuvuits from a Backend : When 
an qo regave cperaticn needs to be done on the 
retrieved reccrds, each t-ackend will do as much. 
degregationea>s Possible in the Breer ats operation 
function of kecord pEoeess 0: 
carries those results to Post Pr 


| 
(4) pegs eS CPecrators ene quest 2 Lepdration Sends 


is message 
ocessing. 


Figure 4.10 Post Processing Messages. 
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Farsed Traffic Unit : This is the prepared traffic 
unit sent by kequest Preparation. 


Nc More Generated Inserts : This message indicates 
that 1nsert request for all the recordset nate a 
Changed cluster as a resuit of an update request 
have been generated and sent to Directory 
Management. 

New Descriptor Id : This message 1S a response to 
tke Dt oeaer: Management reguest for a new 
de=ScripLlor ecde 


Eackend Number : This message is used to specify 
which backend is to insert a record. 


Descriptor Ids ;: This message contains the results 
ef descriptor search by Directory Management. 


Cld and New Values of Attribute being Modified : 
Feccrd Processing uses this nessa ye Oo check 

Bae a reccrd that has been updated has changed 
cluster. 


An Update Reguest has Finished : Record Processing 
Signals Directory Management that an update reguest 
has finished execution. 
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Figure 4.11 Directory Management Messages. 
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and Laisk Addresses: This messaye conrtairs a 


kequest 

request and disk addresses for Record Processing to 
come up with the results for the reguest. 

Changed Cluster tes Toney Directory Managemert uses 


updated record has changed cluster. 


Nc More Generated Inserts : This message indicates 
that all insert requests generated as a result cf 
an update reguest have been sent to Record 

ELocessing. 


Fetch ; Fetch is a special retrieval of informaticn 


for Regquest FPreparation due to an update request 


z 
| 
| 
| 

| 
this message to tell Record Processing whether an | 
| 

| 

| 

with type-IV modifier. 


| 
ate See a a 


Figure 4.12 Record Processing Messages. 
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Sentcoumuaxe€s the attributes in this message anc 
determines wken Descriftor Search for an attribute 
can be performed. Co 

toemteeor— id Groups [Or a Irartfic UN1E =: . 
Concurrency Ccntrol takes the descriptor—id groups 
in this meSsage and determines when Cluster Search 
for a reguest can be performed. 

Cluster fds fcr a Tratfic Uitte eoncur tency 
Ccntrol takes the cluster ids in this message and 
determines wken a request can continue with Address 
Generation ard the rest of reguest execution. 
Release Attrikute ; Directory Management uses this 
message to signal Ccncurrency Control that a 
request has rerformed Pope Coe Seapen on an 
attribute, and the lock on the attribute held [Ey 
the request can te released. 
Release All the Attributes for an Insert: Directory 
Management uses this message to signal Concurrency 
Control that an insert request has performed 
Pocemoeonmocareueon all the attributes, and the 
locks on the attributes held by the reguest can be 
released. 

Release Lescriptor—Id Groups : Directory Management 
uses this message to signai Concurrency Contrcl 
that an insert request has performed Cluster Search 
for a reguest, and the locks on the descriftor—id 
ee US held Ey the request can be released. 

nh Update Reguest Has Finished : Directory 
Kanagement uses this messaye to Signal Concurrency 
Ccntrol that an update reguest has finished 
execution, ard all the locks held by the request 
can be released. 
Attribute Locked : Se ee Ny GontEot Signals 
Directory Management that an attribute is Ilecked 
for a request, and Descriftor Sé€arch can be 
erformed. 

eScriptcr—id.Groups Locked : Concurrency Ccntrol 
Signals Directory Management that the Descrirftor-—id 
gloups needed by a request are locked, and Cluster 
Search can be performed. . 
Cluster Ids Iccked : Concurrency Control signals 
Directory Management that the cluster ids needed Ly 
a request Car continue with address Generaticn and 
the rest of Lequest execution. 

Request Id of a Finished Reguest : Record 
PEecescmiguSi dials .Concurbency Control that a 
ncon—update recuest has finished execution, and the 
pe oR cluster ids held by the request can Le 
released. 


: 
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Figure 4.13 Concurrency Control Messages. 
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( z) pes ae Results Bge@ontains € he weesites orea seenees 
after vpeing ccllected from all the EFackends and | 
acgregated, if necessary. 


Figure 4.14 Host Messages. 
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(S) Cluster Id ; Lirectcry Management sends a cluster 
id to Insert intormaticr Ceneration zorean ieee 
request. IiG will decide where to do the insert. 


(10) Request for New Descriptor Id : When Directory 


Maragement has found a new descriptor, it is Sent 
to Insert Information Generation to generate an id. 
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Figure 4.15 Insert Information Generation Messages. 


EF. TEE EXECUTION OF A RETRIEVE REQUEST 


In this section, we descrite the seguence of acticrs for 
a retrieve request as it moves through MD3BS. The sequence of 


acticrs will be described in terms of the messages fassed 


rketween the MDBS' fprecesses: Request Preparation (REQF), 
Insert Informaticn Géenéeraticn (IIG), Post Processing (PF), 
LTirectory Management (DM), Record Processing (RECF) and 


Concurrency Control (CC). For completeness, we descrike the 
acticns which reguire data aggregation. 

First the retrieve reguest comes to REQP from the host. 
In the present implezentaticn, it comes from the contrcller. 
REQP sends two messaces to FP: the number of requests in the 
transaction and the aggregate cperator of the reguest. The 


third message sent by REQP is the parsed traffic unit which 


46 


goes to [M in the backends. DM sends the type-—C attritrutes 
needed bry the request to CC. Since type—-C attributes nay 
Seheq~c new type-C sul—descri;tors, the type—-C attrikutes 
must ke locked Ly Cc. Once anattribute is locked and 
descrirtcr search can be performed, CC signals DM. CM will 
then ferfora Descriptcr Search on m/n predicates, where on 
is the numker of predicates specified in the guery, andn is 
the numker cf backends. DM then signals CC to release the 
Meek cn that attribute. DM will broadcast the descriftor ids 
for the reéguest to the other LacKxends. DM now sends the 
descriptcr—-id grcups for the retrieve request to CC. A 
descriptcr—id group is a collection of descriptor ids which 
define a set of clusters needed by the request. 
Descriftcr-id groups are locked by CC, since a descrirftcr—id 
group may define a rew cluster. Once the descriptor-—-id 
groups are locked and Cluster Search can be perfcrned, Cc 
Signals —[M. DM will then fperform Cluster Search and signal 
CC to release the locks on the descriptor-—id yroups. Next, 
DM will send the cluster ids for the retrieval to CC. ee 
locks cluster—ids, ‘since a new address may be specified for 
an existing cluster. Once the cluster ids are locked, and 
the request can froceed with Address sceneration and tne rest 
c£ the reguest execution, CC signals DM. DM will then 
perform Address Generation and send the retrieve request and 
the addresses to RECF. Cuce the retrieval has executed prep— 
erly, RKECP will tell CC that the reyuest is done and the 
locks cn the cluster ids can be released. The retrieval 
results are aggregated by each backend and forwarded tc EP. 
FP cc@pletes the agqgregaticn aiter it has received the 
partial results from every t-ackend. When PP is dcne, the 


final results will be sent to the user. 
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IV. AN ABPIICATION OF THE METHODOLOGIES IO ALES 

In the previous chapters we discussed the separate 
topics cf mwethodolocies fcr doing internal and externai 
perfcrmance measurements of database systens and the 
Multi-rackend Database System (MDBS). This chapter fresents 
the application cf tkese methodologies to MDBS. The initial 
discussicn concerns modification to the MDBS software. We 
discuss the decisions made during implementation, mcdifica— 
tion cf the user interface frocess, the backend frocesses 
and the ccntroller prccesses, and the issues resolved during 
implementation. The next discussion centers on the modifi- 
caticns cf the MDBS test environment, which includes test 
envircnment changes and software tools. The final discussion 
identifies measurement programs that were ligplemrented 


outside cf the MCDBS environment. 


A. TEE MODIFICATION CF THE MDES SOFTWARE 


In this section, we begin by presenting the deécisicns 
made ccncéerning the implementation of internal and external 
perfcrmance measurements on MDBS. Next, we discuss the modi- 
ficaticnse cf the user interface and the individual MIBS 
processes. We conclude this section by relating issues which 
are rescived during the iaplementation of the performance 


measurement methodolccy. 


When designing and specifying internal and external 


perfcrrance measurement methcdologjies, decisions rust be 
made as tc the most advantageous positions to place _ the 


checkfrcints, data collections and data aggregations. These 
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Gecisicns are based cn the need to Minimize system overhead, 
emetc cLOVIde | the appropriate level of detail of the test 
data cbhtained. Primitives and data structures must Le devel— 
cped which will allcw the measurement programs to Trenain 
extensiktle and which are ccmpatible with existing systen 
software. A user interface must be developed which is easy 
to use, shculd not reguire the user to possess any special 
knowledge of the interface in order to use-it and shouli 
Maintain data in machine readatle form which will ailcw for 
future exparsion of the perfornance measurement systen. 

tke following implementation decisions are within 
the Ecunds c£ twe corstraints placed upon us by the current 
implementation of MDES along with two constraints we placed 
€n curselves. The first constraint concerns the virtual 
memory available to the processes resident on the backends. 
The cferating syster on the FDP—-11/44 allocates a virtual 
memory of 64 Kbytes. Each of the MDBS backend processes ust 
fit into a virtual memory of this size. The additional soft— 
ware added as a result of jperformance neasurement has to be 
constructed so that it will fit in a the very limited memory 
Space€é remaining in eacn kackend process. The second 
constraint concerns the initial MDBS design reguirenzents 
which called for a broadcast bus between minicomruters. 
Currently a Parallel Communications Link (PCL) is tkéing 
employed as the inter—comfuter message—passing mecharisn. 
Messages passed over the PCL are seyuentially transmitted 
from the sender to tke receiver. This difference in cpfera— 
tion Letween the PCL and the broadcast bus must ke taken 
into acccunt in cur attempt to validate the claims cf MDES. 
Additicnal performance measurement programs must alsc be 
writter to measure message—passing times on the PCL. 

Micwtn imam eenstraint, L.e., Minimizing cverhead, 
Significantly influences our performance measurement design. 


This subject will be discussed in the following paragraphs. 
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The final ccnstraint deals with cur desire to run MDBS urin—- 
feded ry the new performance measurement software. then we 
are nct evaluating the system, we want to fe able tec run 
MDBS with no overhead incurred by the additional pregrams 
and checkpoints of the performance measurement system. This 
is accoufplished by [racketing all performance measurement 
software within special preprocessor instructions which 
allow us to include cr omit the performance measurement 
software during program compilation. A definition file is 
created containing flags which are used to determine the 
secticns of performance measurement code to be compiled. By 
compiling séparate versions, we then have the capapility of 
running MILES without performance measurement overhead or 
with the overhead introduced when we select certain ferticns 
cf the perfcrmance measurement software for compilation. 

Ccmmunication in MDBS is accomplished by fassing 
messaces. fFrocesses which are resident in the same miniccr— 
puter ccmmunicate by using inter—process messages, while 
Frocesses resident in different minicomputers communicate by 
uSing inter-—computer messages. Actions taken by the various 
Frocesses in MDBS are initiated Ey the receipt of a meéssace. 
Acticns end “when that message has been processed and any 
resultant messages have been sent. AS a message is received 
ky a process, the action taken by the process is dependent 
ch the message origination and type. The general MIBS 
process frocedure hierarchy is shown in Figure 5.1. 

The highest level of this process is the main froce— 
dure. This procedure receives the next message and kLased 
upon the originator cf the mzessage, calls a sub procedure in 
the procedure hierarchy. The message works its way deown this 
tree of suk procedtres based upon the originater of the 
message andthe message type. Ultimately, the message 
arrives at a message-handling procedure (message handler). 


The wessage handler has the responsibility of processing the 
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Figure 5.1 The MDBS Procedure Hierarchy. 


messace. In doing sc, it may call other procedures lecwer in 
the hierarchy. MDBS's message oriented approach naturally 
moac itself to checkpoint piacement at this level. 
Selecticn of measurement at this level provides the user 
with sufficient processing detaiis while not overburdening 
the user with excessive infcrmation. A range or S1x to 
twelve checkpoints may be installed in each MDBS frecess at 
this level. DiescenerdaasaAperoOdcn. to the installaticn..of 
checkpfceints is shown in figure 5.2. In this installaticn, we 
insert ckeckpoints Ecth befcre and after every message 
handler. Asa result, we oktain the time cf entry intc the 
Frocedtre and exit from the procedure. The differences 
Fetween these times is the time it takes to process the 


message. 
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Figure 5.2 The MDBS Procedure Hierarchy with Checkroints. 


Measuring at this level presents one problem. the 
system clocks are not sufficiently refined for the 
Frocessing speed of the message—handling routines. The clcck 
on the PLP—11/44 measures time in discrete time intervals of 
cnly cne sixtieth of a second. The clock on the Vax-—11/780 
measures time in discrete time intervals of only one 
hundredtk of a second. In any given time interval, the 
system time may be accessed Ly the performance measurement 
software. This means that access may occur exactly when a 


time interval is reccrded by the system clock or anywhere in 


ketween the recording of atime interval by the system 
e1rock. Because of this condition, the variance of the time 
Measurement would [re approxinuately twice the smaliest 
interval. This variance is significant when it is ccmrpared 
to the time it takes a message-handling routine to process a 
messace. A method must be developed to reduce this variance. 
The scluticn is to send multipie reguests to the messace— 
handling reutine being timed, to record the time for each 
reguest andthen tc compute the average of the reccerded 
times, thereby obtaining a mcre accurate measurement cf the 
true frecessing time. 

In crder to keep overhead to a minimum and tc keep 
the pericrmance measurement system extensible and simple, 
we decide tc place fwinimal ferformance measurement software 
in ar MLES process. Nc processing of test data is dcne in an 
MDBS frocess. All test data is sent to the test-—interiface 
Robt anes fOr aggregation and storage. Since MEBs 15° a 
message—tased system, measurerent control messages and test 
data are transferred as messages utilizing existing Nios 
comMunicaticns routines. A differently—oriented system, such 
as prcecedure—oriented, would require a different approach to 
measurement software communication. 

The installaticn of the checkpoints requires that a 
methcd re devised to collect the information obtained by the 
checkyrceints. The information could be stored locally, trans-— 
ferred tc a central storage MIleccation in the minicomfputer or 
sent to the test interface for storaye. In order tec reduce 
the system cverhead introduced by message passing we deter— 
Mine that tke temporary local storage of data would te mcst 
efficient. AS pointed out previously, one of the constraints 
placed upon the implementation of performance measurepert is 
the virtual memory space available at the backends. Storage 
of the test data generated fron the checkpoints would have 


to be large enough tc contain sufficient timing information 


and small enough tc reside in the constrained virtual 
memory space available to a kackend process. For our timing 
mMeaSurements, the uprer bound cn the number of requests sent 
to a message handler at one time is fixed at one hundred. In 
cther words, we assume that measuring a given function more 
than 100 times will ret provide a statistically significant 
difrerence over measuring that same function exactly 100 
times. Giver this upyer bound, we decide that a static array 
cf 200 records would be small enough to fit in the virtual 
memory of a backend process, yet large enough to hcida 
sufficient amount of test data. Figure 5.3 shows the general 
approach to the placement of the performance measurement 
routine (Timer) which is called by the checkpoint, accesses 
the system clock and m@anages the static array. 

Ancther guestion that pust be answered is the manner 
in which tke checkpoints are activated. Should we activate 
only cne ckeckpcint at a time or multiple checkpoints at 
cnce, We determine that activatiny more than one checkfoint 
at a time cculd intrcduce error into tne medsurement. If cne 
routire (A) which ig being measured called another rcutine 
(B) which is also being measured, the time necessary to do 
timing measurements cr (B) wceuld increase the totai running 
time of (A). Because of this we only ailow the measurement 
cf one reutine at a time. 

The desire tc provide a user interface which is easy 
to use and requires no particular knowledge of test inter- 
face implementation leads us to develop a menu—driven 
system. The modularity of the performance measurement design 
lends itself to easy accesS via menus. The menu—driven 
system is also compatible with the existing test interface 
syster. 

The final problem is how to process and stcre the 
Taw test data received frem the various jprocesses. We 


require that the user have access to both raw data and 
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Figure 5.3 The Procedure Hierarchy 
with Checkpoints and Timer. 


Summarized informaticr. Also, we reguire that the data be 
availarle fcr further machine processing. These proklems are 
eliminated by maintaining all collected data in files. wWken 
Caw data is received from a frecess it is immediately stored 
ina file. Once all requests which are to be timed have 
finished, the file ccntaining the raw data is accessed and 
Frocessed to produce another file containing surmarized 
information on the various message—handling routines which 


have ceen measured. Doves cCOny MOLmuthis, iIntormaticn Ls 


compiled as the underlying cferatiang system ( on the mini- 
computer where the ccntroller software resides ) creates new 
versicns of these files each time the measurement fresgrams 


are invoked. 


2. The Modifications Grete Users iiieemea ce 





Fricr to the igplementation of the performance reas— 
urement methodolcgies, the test interface process consisted 
or these frograms necessary to generate atest datatase, 
load a test database and execute reguestS against the test 
datakase. The implenmentaticn cf performance measurement 
software within the existing software structure of the test 
interface 1s accomplished Ey expanding the existing hier— 
archy ci control and by integrating performance neasurement 
software with existirc test interface software. Figure 5.4 
shows the test interface procedural hierarchy with the 
performance measurement modifications. 

The user selects acticns to be performed [y trav— 
ersing a tree. At each node, a decision is made as to the 
path to follow. By fcllowing certain paths, the user has the 
capakility to generate a datakase, load a datakase or 
execute the test interface. When the user decides to execute 
the test interface, a decision is then made as to what path 
to follcw cn the test interface sub—tree. The user may 
choose a new database to work with, create a new list of 
trafisc Uupits, modify an existing list of traffic Woes 
select traffic units from an existing list for execution, 
select an existing list so that all traffic units cn the 
list may te executed, display the results of external mneas— 
urement crc perform a combination of internal and external 
performance measurement. The user may traverse the tree at 
will meving up and dewn the tranches to accomplish a wide 


variety cf tasks. 
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The Test Interface Hierarchy 
Sel 


with Perfcrmance Measurement Software. 


5. 4 


Figure 


The MDBS software in the test interface =corntaimews 
Frocedtre, called by the other MDBS procedures, to execute a 
reguest (transaction). That is, to forward a reyguest (trans— 
acticn) to Reguest Freparation for processing. This f[rece— 
dure is selected fcr the placement of the external and 
internal performance measuring software necessary to time 
and ranifulate requests. External measurements are taken 
from this procedure immediately before the request is sent 
to Reguest Frepardticn for processing and after the results 
are returned from Post Processing. Software is added te this 
Frocedure to generate reguests to the MDBS processes which 
initialize the message—handling routines for internal 
perfcrmance measurement, generate multiple, identical 
requests in crder tc reduce the timing variance (as fprevi- 
cusly discussed) and to generate the test data ccliéction 
message. The number of multiple reguests to generate is 
provided tc this reutine by a variable defined at compile 
time. This procedure receives the information necessary to 
accomplish these other tasks ky sharing a first-in—last-cut 
Stack anda pointer to the top of the stack with the 
ferformance measurement software. The evaluator interacts 
with the performance meaSurement software to build a stack 
of internal perfcrmance measurement requests. This precedure 
then draws from that stack, lnitializes the messace— 
handling rcutine seé€lected Ly the evaluatcr, generates 
multiple ccpies of the MDBS request selected by the evalu— 
ator, and generates the reguest necessary to collect the 
test data from the process which contains the messace— 
handler teing evaluated. Figure 5.5 shows the relaticnship 
ketween this procedure and the performance measurement soft— 
ware and its data structures. 

in addition. |t&6" vexcerna system timing, cther 
perfcrmance measurement functions provided by the new scft— 


ware include routines which allow the user to 1) £=select 
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Becure 5.5 The Belationship of the Reguest Executicn 
and the Performance Measurement Interface. 


specific MIBS messace—nandling routines to be timed, 2) 
select all ressage—handling routines within a process to be 
timed, °3) restrict the timing of backend message—harcling 
routines tc a specific backend or backends and 4) yferforn 
any ccmkEination cf tke aforementioned selections. The new 
performance measuremert software also includes routines to 
contrel the titing software within the MDBS frecesses, 
collect raw data transferred to the test interface from 
processes within MDBS, process the raw data into summarized 


form and stcre the data for future use. Other routines are 


SLs, 


intrcduced into existing test interiace Soitware to aides 
the message-passing requirezents of the performance measure— 


rent system. 


(a) 


- Tke Modification of Individual Processes 


the PCL processes within MDBS are modified to pass 
fertcrmance measurement messages. All ot the remaining MIBS 
rrocesses received identical ucdification. The sendyreceive 
porticn cf every precess is modified to include the cara— 
biility ‘cL processus perficrmance measurement messages. 
Sendyreceive is used for inter-procesS message fassing. 
Checkpcints are placed in the MDBS processes at the message 
handling (lcw) routine level. A timer routine is placed in 
€ach frocess which receives ccntrol messages from the test 
interface. An initialization message causes the timer 
routine to initialize the data collection array to zere and 
turn cn a selected checkpoint. AS MdDBS—generated messages 
Fass thrcugnh a checkrcint, the timer routine is called. The 
timer rcutine accesses the system clock and stores the 
messace type and time in an array. A completicn message from 
the test interface causes the routine to transmit the data 
collected in the array to the test interface and tc turn cfi 
the checkpcint which is timed. Figure 5.6 shows the medifi— 
cations made to the directcry management process as an 
example cf the implerentation of the yeneral modifications, 


shown in figure 5.3. 


4. Issues Resolved During the Implementation 


MOBS is an experimental database machine. As such, 
it 1S under constant nodification and subject to use Ey many 
system developers. The MDBS software engineering envircrment 
reguires that versions be used to control program modifica— 
tion, but it is impractical te create new versions cf MIBS 


every tize a Single frograr is modified. One soluticn we 
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Figure 5.6 The Heeacearg | pane geuent Hierarchy 
with Checkpoints/Software. 
implemented is the vaintainance of an in-use file. When 


somecne desired to mcdify a frogran, the program is ccpied 


to the developer's private work space. The develorer fakes 


6 1 


an entry in the in-use file which indicates who is currently 
modifying that particular progran. This method allcwed the 
develcper tc modify a program, compile and test the modifi- 
caticn if anh environment away from the main MOBS envircrment 
( in cerder to avoid ccm&promising a functional system ) and 
return tke program tc MDBS upen completion of testing, ae 
methed avoids the possibility of two developers concurrently 
modifying the same prcgram and the ensuing problems. Machine 
time is also at a premium. There 1S no easy soluticn for 
this. Much cf the measurement pust be conducted during ncn— 
Feak hours such as late evening and weekends. This is neces— 
Sitated ty the requirement that tne measurement cf MDES be 
accomrlisked in a stand—-alcne environment. Since the MCBS 
contrcller is inplemented ona time—sharing systen, the 
entire machine has tc be reserved for performance testing so 
that MDBS ceuld ce aur ine cctarvon. 

The perfcrmance measurement system places additioral 
demancs cn MDBS syste message—passiny software. Except for 
cne case, the system responds without protest to this unex-— 
pected lcad. The message—frocessing routines of the MIBS 
kackends are not designed to handle the transfer of 200 
internal performance-measurement messages from a Eackend 
fFrocess to the contrcller. There is not sufficient space 
available tc store tke pointers reguired to access this many 
messaces. The MDBS frograms are easily extended tc account 
for this change in message traffic. 

The MDBS certroller resides ona VAX—11/78&0 which 
cperates under a time-sharing mode. When inter—ccmruter 
messages are passed cr the PCL, the operating system expects 
a confirmation withir a certain time interval. While no 
Froblems occur during the normal operation of MDBS, the 
large message traffic from the backends to the contrcller 
during internal measurement reguire more time than that 


alloted to the ccrtroller during 1ts quantum on the 


foe ii/7e0. sihe result 1S that the controller processes on 
the VAX are suspended while the backend is stili transmiting 
over tke FCL. When tke PCL receives no response it signals 
an errcer and aborts. Obviously, this is not a preblenm wten 
the MIBS system rung Stand alcne. However, SuchmalboOrtion 
does provide more than an inconvenience during the implemen— 
taticn cf the perfcrmance measurement systen. 

Currently, MITES utilizes two different type cf miri- 
computers. This translates into two different operating 
systems, twe differert text editors, two different compilers 
and two different system clocks which record times in 
differing units. Because of this, performance programs int 
the ccntroller processes and the backend processes are net 
identical. Different access mechanisms for system timers 
must ke developed and a routine must be developed te ccnvert 
the times received from the Facxends into the equivalent 
time units cf the ccntroller. Aadaerondl time . and eficrt 
are required to beccnre sufficiently knowledgeable on the two 
systems in crdér to Eégin implementation of tne perfcrmance 


measurement methodolccy. 


Cmeoer MODIFICATION CF THE MDES TEST ENVIRONMENT 


In ccnducting performance reasurements, one demands that 
all the measurements Fe consistent as well as reprocucible. 
There shculd be no inconsistent, unexplainable results. 
Further, the results should te reproducible with re-runs. 
This section discusses the necessary changes in the test 
envircnment to insure consistency and reproduciblity. Then 
we present the software tocls used to make the testing 


easier ard smoother. 


1. Necessary Changes to the Test ean seonieone 


The methodolccgies for internal and external ferforn— 
ance reasurements ona datarase system have one preregui- 
Site. The results must not be accidental. These results 
need tc bre consistent and reproducible. To achieve consis— 
tency and reproduciklity, we must be able to contrcl the 
test environment. Every scientific experiment reguires the 
test éenvircnment to ke ccnatrolled, to insure that all 
factcrs effecting the experiment are known. 

The experimental MDBS, the system to ke tested, has 
its centrcller frocesses running under a VAX/VMS envircn— 
Ment. This requires these frocesses of the controiler to be 
run Simultaneously with the other non-system processes ina 
timesharing environment. Under tnis environment, the 
results oftained would be erratic and inconsistent. To 
alleviate this, several preliminary steps are taken fricr to 
final testing. The tests are run stand-alone with all cther 
logirs tc the ccmputer disabled. All processes are civen 
the highest possible real—time priority. Swapping cut of 
Frocesses in the wait state is disabled to retain the 
processes in the physical memory. Page faults are disabled 
Ey increasing the working set size to the size of the image 
of each frocess. In this way, the VAX/VMS system apfears to 


the evaluatcr as a Single user systen. 


2. sOftwate Toole £or eke Tesee on weEnoniveme 


An evaluator should understand the system tc be 
tested, determine the various parameters to be altered, 
specify the various data to be coliected, and interpret the 
results. Tedious and busy work, such as modifying the input 
set cr the system configuration, can be done manually and 
are time—-ccnsuming without froper tools. Nevertheless, 
these modificaticns are necessary, and can be automated by 


using software tools. 
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In [Ref. 9], software has been provided tc generate 
a datarase and a request set, lcad the database, and run the 
reguest set against the datakase whicn can all be used in 
the testing of MDBS. This allows for easy creation and 
modification of the selected database and requests. The 
System scftware needs to be mcdified during the testing to 
accommodate such things as changes in the number of tackerds 
Feing used Lty the system and whether or not internal testing 
is tc be performed. Fach change reguires a recompilaticn of 
the system software. To facilitate this change and to 
insure cnly recompilation of necessary files, the Unix 
‘make’ command is used. Briefly, execution of this ccimand 
would check a file created Ey the author. Thats. 11 levwould 
indicate all interdeyendencies of all files of MDBS. pied 
file bas keen changed, all cther files effected by this 
Change will automatically ke recompiled and relinked ufon 
executicn ci the 'make' command. In this manner, the systen 
could ke reconfigured with ease and with the assurance that 
all effected files are changed. Using these software tccls 
for the test environment and with proper control of the test 
envircnnent, the tests are made easier to conduct and 


contrel and are knowr to be consistent and reproducitle. 


Ce. ALDITICNAL MEASUREMENT SOFTWARE REQUIREMENTS 


In crder tc ccapletely evaluate MDBS, the message 
passing mechanisms must be monitored to determine the time 
reguired tc pass Ecth irter-—computer and inter—process 
messaces. Although the measurement of these messages cculd 
cccur during the execution of MDBS, the environment under 
which tke messages are passed could be more easily 
contrclied if the messages are evaluated outside cf the MIBS 
envircnoment. The results of these measurements are ccntained 
in the next Chapter VI. 
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1. Inter—-computer 


—_— a eee co 


(c= 


essage Processing Measurement 


New software does not have to Ee developed to 
measure tke time recguired to pass messages on the PCL. - 
Programs are provided by the manufacturer of the PCL which 
measure the message—fassing time. The evaluator is given the 
capakility of specifying which ncde on the PCL is to receive 
the message, the message length and tne numcker of messaces 
to send. The software generates and sends the messages, then 
Frovides tke total time tc transmit the messages tc the 
€valuator. The PCL is implemented as a ring bus. Because of 
this style of itplerentation, we decide to send messages 
from cne selected node to itself. The times obtainec are an 


upper bound to the irter—computer message passing time. 


Ercgrams are written for the inter~process message 
Processing measurement. To determine the time reguired to 
Fass a message, we developed two programs. The first precgran 
gets the time, generates a selected number of messages witha 
a sé€lected message length, and sends them toa ee seccnd 
Frogram which receives the nmessages and then gets the time. 
we cun the first pregram at a hiyner system priority than 
the seccnd to frevent the system from process switching 
refore all the messaces have been generated. After genera— 
tion cf all messages Ly the first program, we then set the 
systeg priority of the sending program below that cf the 
receiving rogram, tkereby forcing a process Switch. We can 
then ccmfute the average time it taxes to pass a _ sincle 
messace cn the machine. To obtain a higner degree cf accu-— 
racy we must account for the time it takes the system to 
SWitch frocesses and the time it takes the system to alter 
the pricrity of the sending process. Programs are written to 


account for these times. The program written to account for 
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the tire necessary tc alter the priority merely gets the 
time, alters the priority a selected number of times, tten 
gets the time again. There are two programs necessary to 
determine the time tc process Switch. They are identical to 
the twc fregrams mentioned akove except that the number of 
messages between process Switching is set to one. Utilizing 
the akcve programs ‘xe are able to obtain the inter-—prccess 
mesSsage—rfassing times on Ecth the PDP—11/44 and the 
VAX—-11/7€0. The next chapter will discuss the selected 
Gataktase, request sé€ts, and procedures taken to run the 
actual benchmark of VYIBS. 
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V. JHE BENCHMARK OF MDBS 

The ccnstruction cf the test datapase and the selection 
of reguests are very important in the performance measure— 
ment cf a test database system. The test database shculd he 
representative of a Leal datakase, but, as presented in 
[Ref. 7], the test database shculd be modeled independent of 
any specific database. Both the Test database and the 
reguests selected shculd be properly modeled to allcw fora 
complete exercise of the target systen. At the same tine, 
Farameters must not kre selected randomly, but rather should 
ke created to prcevide the evaluator flexability and ease of 
€valuaticn. In this chapter, we first describe the manner 
in which the test database is modeled. We then describe the 
reguest set which is used in the performance teasurement 


experiments. 


A. THE SELECTED DATAEASE 


Since MIBS is an experimental database systen, Lt as 
constantly leing improved and enhanced. For this reascn, 
the test database is cesigned to facilitate measurements by 
being easily expandabtle. A.distinction will be made in the 
following discussions between the design of the test data— 
tase, which allews fcr future measurements, and the actual 
implementation of the test datakase used in the measurement 


experiments. 


1. The Design gf the Model Database 


Several factcrs must Le considered in the design of 
a model database. Since the system being measured can be 


configured with eitker one or two backends, the ‘work! 
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required to frocess a request has to ve evenly divisitle to 
accommcdate the use cf either one or two tackends. The 
types cf work involved are attribute search, descriptcer 
search, cluster search, address generation and the retrieval 
and selecticn of reccrds. 

fatle I displays the three configurations to Le used 
in the performance méasurement of MDBS. The coniiguraticns 
have keen selected tc simplify the verification of the MIBS 
performance and capacity clains. these Claims are - to 7) 
halve the response time by doukling the numter of tackerds 
and keeping the size cf the database constant and 2) f@rain- 
tain a ccnstant respcnse time Ey doubling both the numter of 
kackends and the size cf the database. AS shown in Tatle I, 
going frem Test A te Test 2B Maintains a constant database 
size Eut allows the database to be evenly split Létween two 
Packernds. Conversely, going from Test B to Test C doubies 


the size of the datatase at each backend. 


- 
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TABLE I 


The EFenchmark Configuration 


ss “Nc. of Backends | Mbyte/backend 
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10 properly evaluate a database systen, VaLricus 
record sizes need to ke used. The sizes are chosen Lased on 


the size of the unit cf disk management. Pipes, this is 


GY 


the Icgi¢cal track, Sy cra occ MDBS frocesses information 
from the secondary memory using a 4kbyte iogical track. 
Given a tlocksize of 4Kbytes, we recommend constructirg the 
éatatase with record sizes of 200 bytes, 400 bytes, 1690 
kytes, and 2000 kbytes [Ref. 7]. This gives a range or 2 to 
zO reccrds per block. This also creates an envircnment 
where four separate databases, corresponding to the fee 
record sizes, must be generated and tested for each configu— 
GFatich given itelableae Takkle II jives the corresperding 


relationshif between records and blocks. 


| TABLE Il 














| 

| The Reccrd-and—Block Relationship | 

— ee a ee ee | 

| Fecord Records { | 
ed ae ote 

| in Bytes | BLOCK | 

| 200 | 20 | 

| 400 7 10 | 

1000 | 4 | | 

| | z000 2 | 

|... rrr i 





As described in Chapter III, the target systen 
stores records in clusters. Five cluster categories have 
keen selected for use in the creation of the model datatlase. 
The distinguishing characteristic of a cluster categecry is 
the numter of blocks used to store the records in the 
particular categcry. Table III outlines the sizes of each 
of the five cluster categories. One final note, the numker 


of bliccks per cluster must be even. Thus, when the numtker 
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cf kackends is ircreased from cne to two with the number of 
records in the database remaininy constant, we are guaran— 
teed that each tkackend will have the same number of Elocks 
fer Ciuster. For €xample, when the cluster cateéegcry is 
small, each backend would have one block for the particuiar 


cluster, insuring an é€ven distribution of the datakase. 


| 
: 


TABLE Iift 
The Cluster Arrangement 








Clusters Category|Biocks/Cluster 
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SEV ere uradta in fabless ill and III, we can 


construct a matrix cf data which represents the numter of 
records rer cluster category. Table IV, indexed using the 
cluster category and the record size, details this infcrma- 
tron . The number cf records per cluster is oktained by 
Bultiplying the Records/Block results from Table II by the 
corresfpendiny BlocksyCluster results from Table III. 

The remaining considerations when developing a test 
datakase involve the specification of the directory struc- 
ture for tke particular record type. Poe MBS, amrecerd 
template, which describes the record structure is defined. 


The record template defines the number of attributes in the 
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TABLE IV 


The Reccrds per Cluster Category 


Number of Records per Cluster | 
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record, andfor each attrikute, the attrikute nare anc the 
attrikute type (either integer or string). Given a record 
template, the directory and non—directory attributes are 
specified. For each directory attribute, a descrirtcr type 


and descrirtor ranges are defined (see Chapter III).. 


This section examines the implementation decisicns 
made when specifying the test database and the testing 
strategy. Ihe current version of MDBS, the primary—memory-— 
kased directory management, stores the directory takles, 
1.¢€., the AI, DDIT, and CDT, in primary memory. Given the 
primary wemcry limitations of the backend, we are fcrced to 
limit the variables mentioned in the previous secticn. Cull 
first decision is to limit the size of the test datakase to 
a maxituga cf 1000 reccrds per ktackend. Table V displays the 
configuraticns which are used in the performance measure— 


ments of MDES. 


TABLE V 


The Measurement Configurations 
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Five different system configurations are needed for 
the MIBS performance measurements. Rests A. foe 5. pcanc C.£ 
are conducted withcut internal performance software in 
mlace. Test A.E ccnfigures MDBS with one fcacxend and cne 
thousand records in the test database. Restmea COMelGures 
MDBS with two backends and one thousand records split everly 
retween the backends. Test €.E—£ also configures MDES with 
two kackends, but, the size of the database is doutkled to 
two thcusand records. Test A.I and B.I are conducted with 
internal ferformance software ir place. Test A.I configures 
MDBS with one backend and one thousand records in the test 
dataLkase. Test B.I configures MDBS with two backends and 
cne thousand records split evenly between the backends. 
Using these five configurations, the verificaticn of the 
MDBS yferfcrmance and capacity claims is simplified and the 
perfcrmance measurement methcdology Creconpu ting the 
internai mé€asurement cvernead is tacilitated. 


Cur second decision fixes the recoraq size at 200 


kytes. The 200 byte record wihimizes the primary memory 
required to store tke record template. iimeadce tualit yd 
record of 198 bytes is used. The record consists cf 33 
attrikutes, each reguiring 6 rFytes of storage. The reccrd 


template file used in our experiments is shown in Figure 
Geis Ci the 33 attributes listed, INTE1 and INIEzZ are 
directory attrigugece MULTI and STRUO to STR2S are tenes 
directcry attributes. 

In cur next decision, the descriptor types and the 
descriftcr ranges fcr the two directory attributes, INIE1 
and INTEZ, are defined in the descriptor files (see Figure 
Ge ae The values fcr INTE1 are classified by using five 
type-A descriptors, €ach of which represents a range cf 200. 
The values for INTE2 are alsc classified using type-A 
descrirtces. The first twenty-three ranges for INTE2 cover 
40 values, with the last range covering 80 values. the 
noh—unifcrmity of the INTE2 descriptor ranges is caused Ly a 


Size ccenstraint in the Concurrency Control process. 











ge ne ee Tams mg ap ys cnn cea me en re sama  - 
| Attribute Name | Attribute Type | 
INTIE1 : integer | 

INTE2 integer 
Mae ck SELIG | 

STEQO STEIN 
STHROQ1 string } 
| 4 | : | 
es Be - | 
| 5 ig string | 
te st 
Figure 6.1 The Record Template File. 

Fy utilizing the attrifute and descriptor files, the 
record file is generated. INTE? and INTE2 are identieay 


keing the next sequential number after the previous record, 
starting at 1. Therefore, the one thousandtno record would 
have the ({INTE1, INTE2) pair set to 1000. The MULTI 
attrikute, which is cf type character string, 1s set tc Cne 
for a datakase of orly 1000 fecords. The intent of this 


attrikute 
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The Descriptor File. 


Figure: 6.2 
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Figure 6.3 


The Record File. 


is to increase the tcumber cf records per cluster in the 
datakase. This is dene by setting MULTI to Two, Three, 
enc o, for each (IKTE1, I Nae 2} pair in the datatase. 
Therefore, to double the size cf the database, every (INTE, 
INTE2) yairc will have an associated MULTI attribute with 
values of Cne and Twce. The remaining attributes, S1kCGmme 
STR29, are Set tO Kxwax as wri ier: Figure 6.3 depicts the 
general laycut of tke record file for 1000 reccrds where 
MULTI is set to Cne. 

Given the structure described, our last decisicn is 
made for us. The specification of 24 descriptors fer the 
PNTEZ ateracute, ccupled with the record file structure, 
generates a datatase that contains 24 clusters. The firse 
23 clusters correspond to the small cluster category, saad 
each ccntains 40 reccrds. The last cluster corresrfonds to 
the snmall—redium cluster category and contains 80 records. 
To maintain consistercy in the retrieval réeyuests (discussed 
in the next section), we avoid any rejyuests that access the 
last 8Q records in the test database using the INTE2 


attrikute. 


Bo. 2EE BEQUEST see 


The recuest set used for our performance meaSuremert is 
given in Figure 6.4. The retrievals are a mix of Single or 
double predicate recquests. Since the majority of the werk 
done cn a database is to retrieve data, we limit the neas— 
urements to only retrieve requests. In every reguest, 1/2 
of the target attribtte values for each record is returned. 
The first retrieve ig a request for only two records fron 
two separate clusters. The second reguest retrieves 1y4 of 
the datalkase. Seven of the 24 clusters must be examined. 
All records in each cf the first six clusters are retrieved. 


Cnly 1/4 of the seventh cluster, defined by tke range fron 
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(INTE1=10) or (INTE1=230) 

(INT E2 < 250) 

(INTE2 < 500) 

(INTE1 < 1000) 

~ (INTE1S200) or (INTE1>801) 
 {INTE1S$400) or (INTE12601) 
| 7 (INTE? < 201) 

(INTE? < 401) 


9 | (INTE 1$201) OF (INTE12800) 
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Figure 6.4 The Retrieval Requests. 


241 tc 280, is retrieved. ieee stntrd request, 1/2 cf the 
datakase is retrieved. Thirteen of the 24 clusters must be 
examined. All records in e€ach of the first twelve clusters 
are returned. Cnly 1/2 of the thirteenth cluster, defined 
Ey the rarce from 481 to 520, is retrieved. The systen 
searches only fcr records having values in the range fron 
pemetoc S00 in this cluster. 

The entire database is examined in the fourth reguest. 
The fitth request retrieves 2/5 of the database. The guery 
is divided into two fredicates, EOMOKtLalh adil Tecortds fron 
the first five clusters, and the last four clusters. The 
Sixth reguest is a retrieval cf 4/5 of the database. Again 
the guery is divided into two predicates, to obktair all 
records frem the first 10 clusters, and the last nhine 


clusters. 


vo. 


The seventh and eéighth recuests are Similar in intent. 
The seventh reguest examines 10 clusters, requiring criy 1 
record tc ke retrieved from the 6th ciuster and needing ali 
records frcm the )iirstetave eisecus. The eighth reguest 
examines 15 clusters, reguiring only 1 record tema 
retrieved from the 11th cluster and needing all records from 
the first ten clusters. The ninth and final request is 
Similar te the firth reguest. But unlike the fifth reguest, 
ten additicral clusters must te examined. Only twe of the 
records with INTE1 values of 201 and 801, are retrieved from 
the ten additional clusters. All records in the remaining 


nine clusters, like the fifth request, are also obtained by 


this retrieval. Takle VI, a presentation of the nurker of 
clusters e€xamined versus the percent of the database 
retrieved, is a synopsis of the previous discussicr in 


tabular fora. 

The request set in Figure 6.4 is not intended tc be 
representative of a ccmprehensive and complete request set. 
The gcal is not to exhaustively measure and evaluate MDES. 
Father, we focus on applying the performance measurement 
methcdclcgy to MDBS to validate the basic performance and 
capacity claims cf tke systen. We feel that these reguests 
are SUELICICHt fOr Sven wea validation. We will refer to 
these rine requests, i1.e., retrievals, by their reccrd 


number in subsequent discussicn. 
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TABLE Vi 
The Nugker of Clusters Examined 


and the Percent of the Database Retrieved 
































{ Rkeguest | Number of | Volune of | 
i Numcser | Clustezrs | Database 
| { Examined a Retrieved 7 
1 ‘ 2 : 2 records 

| Zz 7 25% | 
{ 3 13 { 50% | 
| 4 24 (all) 100% 
| 5 g LOZ 
| 6 19 80% 
| a | 10 20% + 1 record 
! 8 | 15 40% + 1 record 
| 9 19 4O% + 2 records | 
es ee) 
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VI. JHE TEST RESULTS 

in this chapter, we present the results obtained fron 
the fperforfance meastrement cr MDBS. MDBS 1S Current, 
configured with the [rimary-memory—based directory manace— 
ment. In this veErsicrE of MBBS, the directory tables, ~2acu 
wie Ad,. LLil,2and CDI, are stored in the primary memory. We 
expect tc achieve different results when version F, the 
secondary—wemory—basec directory management is implemented. 
The test interface is utiiized to send the retrieval 
reguests discussed in the previous chapter to MILES for 
processing. Each reguest is sent a total of ten times fer 
datatase configuraticr. The response time of each recuest is 
recorded. After some trial runs, we compute the stardard 
deviaticn. We determine that ten repetitions of each request 
is sufficient to provide the desired accuracy. 

The internal precessing times of the messaye—-hardling 
routines which are tsed to process a retrieval reguest are 
also timed. retrieval (1) and Retrieval (2) are selected to 
conduct internal timing. These reguests are selected since 
they retrieve the smallest portion of tne test datakase and 
the processing time fcr each reguest iS minimal. Recall that 
€ach message—handling routine is timed independently cf all 
cthers and that each routine must process multiple requests 
so that an accurate average may be computed for the time 
required tc process that request type. Sixteen message— 
handling routines are reguired to process a retrieve 
request. If we send twenty requests to each routine, a total 
cf 32G reguests must be processed by MDBS. Based cn these 
figures, the time required tc conduct the internal ferforn— 
ance measurement of a retrieval that has a response time ci 


twenty seccnds will be approximately 107 minutes. T hake 
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figure dces not include the administrative time required to 
process the internal measurement data. For this reascn, we 
limited the internal performance measurement reguests to 
Fetrievals (1) and (2). 

Additionally, we also limited the number of repetitions 
per message handler to twenty. This is done to reduce the 
Frocessirg time fer mwessage handler. However, this decision 
reduces the accuracy of the internal performance measure— 
ment, frem ten—thousands to hundredths of a second. ‘Thus, 
the internal performance measurement times provide cnly a 
Tougn estimate of the time required to handle the respective 
bessaces. 

The first section of this chapter contains the external 
timing results cbtained from our measurements. We also 
discuss the performance and capacity improvements crtained 
ky adding tTackends. In the second secticn we present the 
results frem internal performance measurement. The final 
secticn examines the inter-process and inter—comfuter 
messacé frocessing times. One final note, the units of 
measurement presented in the tables of this chapter are 


expressed in seccnds. 


A. IEE EXTERNAL PERFCRMANCE RESULTS 


Table VII provides the resuits of the external perfora— 
ance measurement of FMDBS without the internal perfcrmance 
measurement software. There are three parts to fTatkle VII. 
Fach fart contains the mean andthe standard deéviaticn cf 
the respense times fcr Retrievals (1) through (9), which are 
cutlined in Chapter V. The three parts of Table VII repre— 
sent three different configurations of the MDBS hardware and 
the c¢atakase record capacity. Vicmmeeacotr cart has MiLBS 
configured with one Eackend andthe datakase loaded with 


1000 reccrds. The second part has MDBS configured with two 
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TABLE VII 


The Response Time 
Withcut Internal Performance Evaluation Software 
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kackends, with the database containing 1000 records, split 
evenly téetween the backends. The third part has MDBS config— 
ured eth two backends, with the database doubled to 2000 
records, aiso split evenly between the backends. In Tabi 
VII we netice one data anomaly, the standard deviaticn for 
request (9) in the cne—-backend—with—1000—records configura— 
trou Since we did not conduct an ainternal performance 
measurement on this request, we are not sure what causes 
this skewed standard deviation, and hence wili not attempt 
to cfifer an explanaticn orf this anomaly. 

Given the data fresented in Table VII, we can now 
attempt tec verify cr disprove the two MDBS performance 
claims. We begin by calculating the response—time improve— 


ment cf MDBS. The response—time improvement 1s defined to be 
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Figure 7.1 The Response-—Tise—Improvement Calculation. 


the percentage imprcvement in the response time crea 
reguest, when the reguest is executed in n Lackends as 
cpposed to one tackend and the number of records in the 
dataktase remains the same. Figure 7.1 provides the formula 
used to calculate the resjcnse-time improvement for a 
Farticular reyuest, where Configuration 3B represents n tack— 
ends and Configuraticn A represents one backend. Thus, in 
Table VIII we present the resfonse-time improvement for the 
data given in fable Vil. Notice that the response-—tine 
improvement is lowest for reguest (1), whicn refresents a 
retrieval cf two reccrds of the database. On the other hand, 
the tLrespconse—tine improvement of reguest oy which 
retrieves all cf the datakase information is highest, 
apprcaching the upper bound of fifty percent. In general, we 
find that the respcnse—-time improvement increases as_ the 
humber of records retrieved increases. This seems to sufpert 
a hypethesis that even if the database grows, the respense— 
time improvement will remain at a relatively high (retween 
40 and 50 percent) level. 

Next we calculate the resfonse—-time reduction ci MDBS. 
The resecnse-time reduction is defined to be the the reduc-— 


tion in response tire of a request, when the request is 
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1 and 2 Backends (External Measurement Only) 


Reguest| Response Time 











No Internal— 


Feasurement Software 
Oe a es eee ee ee eee 


————— 
Number Improvement 
1 Ore Ory | 
eZ 45.14 i 

2 | bie Oe 

4 48.94 

= 47.27 
6 48.81 

j 7 45.93 
8 Wie t9 i 
9 Toa 
1K Records | 
| 


pn nee ane Ses hee en Petes Se CES ees BRE ates SD Eats SE Gere Gees Retin Smeets Sees Me Sa Se Sens 


ene es saa OE pc, fete Ent, I eens Ue ee GNA tentpee, tna tentsaas OP Gace, neee ethan Seen etette aan SEPA tears cinanes tanta sal 


; 
| 
F 
| 


executed in n backends containing nx number of treccrds as 
opposed to cne backend with x number of records. Figure 7.2 
Frovides the formula used to caiculate the the respense-time 
reducticn fcr a particular retrieval reyguest, where ccnfigu— 
raticn A refresents cre backend with x records and configu— 
Iaticn B refresents n backends, each with x records. In 
Table IX we present the respense—time reductions for the 
data given in Table VII. Notice that the response-tine 
reducticn is worst for reguest (1), which represents a 
retrieval of two reccrds of the database. On the other hand, 
the resEcnse—-time reductions fer the retrievals which access 
largex pertions of tke database, requests (4) and (6), have 
chnly a saalil resfonse-time reduction. In generai, we found 
that tke response-time reducticn decreases as the number of 
records retrieved increases, 1.e., the response time remains 
virtually constant. Again we seem to have evidence to 


Support the hypothesis that, as the size of the database 
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increases, the resfcense-time reduction will decrease tca 


relatively low (0.1% or less ) level. 


---—-—----- = —--—--—------- 


~ 


| The Response 
| Time of 

le Control ativon 7: 
L 


Sa ae aed 





Tre. | 
Ecnse—Tize = 100R #* 
€ 


os duction 


aa a a 


| The Resporse 
Tine of 
| Conf i guint 16m eA 


ee ee 


(0 etree Seis CEES pee SE ee 
ead 


is ee eee ee ge eS 
Som ee dete Oy ee Se es SR pe Be Gee ee gee, 


areye 
3 
| 
| 
| 
| 
| 
| 
| 
| 


Figure 7.2 The Response—-Time—Reduction Calculation. 
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TABLE 1 


The Kesponse-Time Reduction 
In Doukling the Database Size 
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Takle xX provides the results of external performance 
measurement of MDBS with internal performance measurement 
software it place. There are two parts to Table X. Each 
part contains the mean andthe standard deviaticn of the 
response—timres for the reguests (1) through (6), which are 
Outlined in Chapter V. The two parts ot Table X represent 
two different ccnficsurations of the MDBS hardware and the 
database record capacity. Fart one has MDBS configured with 
one Lackerd and the database lcaded with 1000 records. Part 
two has MDBS configured with two -tackends, with the database 
containing 1000 records, split evenly Lletween the rackends. 
We did ret measure the respense tigeS with two thousand 
records distributed cver two Fackends. We felt that ne addi- 
tional informaticn wculd be gained by conducting the meas— 


urements. 


~----------- —-- + ----------------- 


TABLE X 


j The Ré€sponse Time (in seconds) 
With Internal Ferformance Measurement Software 
































| 
| 
| | 
| Request | ~Cne Backend | Two Backends I 
Number | 1K Records | 1K Records ! | 
mean - stdev mean | oe | 
| 1 Jeu 9.0436 5.319 10.0474 | 
2 12.4731 0172 T4010. 02771 | 
3 250 903110.0 1197 |e lee see O: BB86! 
| 4 oO. 750 0293741] Zo. 40210. 0596 | 
= 2069721020275) ie 2a O52 01] 
i | 6 41.262|0.0331] | 21.51710-0575] { 
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An interesting arcmaly is discovered when we ccmpare the 
response times cf the external and internal performance 


measurement tests, 1.€., parts one and two of Tables VII and 
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X for requests (1) threugh (6). We actually found a general 
improvement, from 0.1% to 5%, in the response times ci the 
requests when the internal performance measurement software 
is part cf the MDBS code. One hypothesis is that this is 
due te tke manner in which MDEBS is implemented on the tEack— 
ends. cCwtrrently, there is not sufficient physical memory 
avaiiatle cn each backend. The result is that disk cverlays 
are used tc Swap in the code necessary to run MDBS. The 
additional internal performance measurement code may cause 
the cperating syste to overlay differently, thereby 
Eenefiting the overall performance of MDBS. We still 
relieve that there ig an overhead induced by the internal 
measurement code and Table XI provides evidence fry demcn— 
strating that the response-time improvement achieved by 


adding a E-Eackend is net as good as that of Table VIII. 
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The Response Time Improvement Between 
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BE. TEE INTERNAL PERFCRBANCE RESOQiTS 


Table XII provides the results of the internal ferforn— 
ance measurement of MIBS for a retrieval reguest. The tines 
measured fer each wmessage~handling routine are given {for 
bkoth reguest (1) and (2). The message—-handling routines are 
listed with the MDBS process which “contains the ~ roc? 
Althcugh the results are given to four decimal places, we 
cnly trust the accuracy to the second decimal place. ithe 
reascn fer this has fFeen discussed in the introducticn to 
this charter. We are not exprerts on the MDBS system. We can, 
however, make a few comments on Table XII and we are sure 
that these who are experts can use the results contained in 
fable XII tc draw mcre in—depth conclusions on the systen. 
We sé€e that the ccntroller frocesses, ieee s Request 
Freparation and Post Frocessing, spend very little time in 
Frocessinrg the retrieval reguest. Tnis is a major design 
goal cf MDES and 1s hecessary to prevent a bottleneck at the 
contrclier when the number of backends increases substan— 
tially. It appears that this goal is met successfully. We 
also ckserve that the results obtained from Concurrency 
Contrel are consistert and cf short duration. This “ge 
expected since there is only one reguest in the system at a 
time and ne access ccntenticn can occur. These tables should 
then ke considered as containing the pest-case times. The 
Hajority of work done in the backend is at Record 
Processing. Observing the process timings in Record 
Frocessing, we see that, for both reguests, the additicn cf 
an extra ~ackend reduces the record processing time by 
nearly half. 


C. TEE FESSAGE FROCESSING RESULTS 


Table XIII provides some average times relating to 


inter—prccess message passing times on the contrclier and 
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Aes a kL 
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Frocessing Times for a 
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TABLE XIIiL 


Inter—process Message Passing Times 
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{| Time to Time to | Time to 
Location |Construct|] Receive Pass 
{ Message | Message | Message 
l { 
Cerone 0.00249 | 0.00264 | Hev0a20 | 
Eackend 0.00830 0.00410 | 0.01250 
aoe tS SSP <n ene a eR 





(Fe ee ee ee a a ee ee ee oe Se 


ae 


the -ackend. Messages are transmitted between two frocesses 
co Ecth the controller and tackend. Both the numker of 
messages and the message length are varied. On the 
contrcller, the numter of messages is varied from 1 tc 100 
woile the message lergth is varied from 2 to 2000 k;ytes 
(size of the message puifers in MDBS controller). On the 
Fackend, the numter cf messages is varied from 1 to £0 while 
the message length 1s varied from 1 to 1000 bytes (s1ze or 
the message buffer in MDBS tackends). It takes the Eackend 
twice as long to jfrocess a message aS it dces the 
contrclier. We ktelieve the reason to be hardware processor 
speed. An independent test showed that this relaticnship, 
c{ twe to cne, holds in how long it takes to precess am 


assignment statement cn the respective nardware. 


ou 


In Table XIV we provide information concerning the time 
to precess inter-computer messages on tne PCL. Messages of 
length less than forty are overShadowed by the overhead of 
the FCL. There exists a linear relationship between the 
message length and tte time tc pass a message as the message 
length exceeds 100 bytes. we Can therefore expect a linear 
perfcrmance from the FCL for the majority of the MDES inter— 
computer messages. The next: chapter will contain scme 


concluding remarks and discuss areas for further resé€arch. 
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TAELE XIV 


Inter—computer Message Passing Tines 
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Lengt Pass Change | | 

(Bytes) |Message ! | 

1C 9.0949 | 0.0000 | 

|S ZOmNiNOROCSHmINNO.0002 | | 
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@ Z @ 

| 100 0.1026 | 0.0007 | | 
260 0.51136 | 0.0100 

| doc | 621339 | Ol0107 | | 

| 5C0 | 0.1439 0.0190 | | 
1000 0:1943 | 0.9504 
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VII. THE CONCLUSION 


Aw. A SUMMARY OF THE FERKFORMANCE MEASUREMENT METHODOLOGY 


1. The Internal EFertormance Measurement Methodclogy 


The internal pert crmance measurement methcdclcgy 
Frovides the strategies and lccations for the placement of 
checkrcints. It further provides the kinds of performance 
data tc be collected. This information enables a Letter 
understanding of the target system by measuring certain 
capaltilities, such as the time spent in individual 
FLOCESSES. Using this information of how the system 
performs internally ray lead to design modifications cr to 


fine-tuning of the system for increased performance. 


2. The External Ferformance Measurement Methodclogy 


The external performance measurement methcdclcgy 
Frovides the strategies for a macro view or the database 
systen perficrmance by measuring the system as a whole. We 
focus on the measurement of the response time of the target 
syster after the issuance of a reguest. A test datakase and 


a test reguest set 1s generated usiny software tools. 


ining tke Internal and External Measurement 


. 
a RS eR <p 


The natural ccmbination of the internal and external 
performance measurement methodologies is synergistic ir the 
amount cf informaticn that is provided. The overhead 
incurred when using internal performance measurement ccde is 
accurately determined using this methodology combinaticn. 
The external performance measurement timings can be frorerly 


interpreted using’ the internal performance measurement 


results. Ey combining the two measurements, the whole of 
the measurement results is more meaningful and userul tkan 


Gre iarcividual results. 


Be A SUMMARY OF THE FETHODOLOGY APPLICATION 


Thrillirg and unexpected results are collected when this 
methcdclegy is applied to a target system, i.e., MDBS. 
First, the methodolcgy proves itself to be successful in 
attempting to verify the pe réormance and capacity claims of 
MOBS . This results from Feing able tc collect sufficient 
data cn a target system to make definitive statezents 
concerning its performance. The application of this methcd- 
erogy to MDES 1s alse surprisingly easy. 

A seccnd result, is that the perficrmance and capacity 
claims of MIBS have keen validated. These claims are: 1) 
that ky increasing tke number of Lackends used as a fart cf 
the dataltase system ard by keefing the size of the database 
constant, the respcnse time of the same transacticns is 
propcrticnally decreased, and 2) that by increasing the 
number cf Eackends and also increasing the size of the data-— 
Fase, the response tire remains relatively constant. These 
Ciaims are validated Ey the results given in Chapter VI. 

These spectacular results provide a wealth of infcrma— 
tion fren which several conclusions can pe made. we find 
that under MDBS, the response-time improvement increases as 
the numter of records retrieved increases. Alsc, the 
crespcnse—tine reducticn decreases as the number of records 
retrieved increases. Though the performance measurement 
results indicate an ifprovement in the response time cf the 
reguests when the internal performance measurement scftware 
is part cf MDBS code, it is felt that this phenomenon is the 
result of daffering system overlays and that the irdcuced 
overhead of internal measurement code still needs te be 
caleuljlated. 


\O 
dad 


The results of the internal performance measurements 
indicate that the ccntroller frocesses, 1.ety he guest 
Preparation and Fost Frocessing, spend very little tize to 
Frocess the retrieval request. The results obtained fron 
Concurrency Control are both consistent and of short dura— 
t16n,, dS sexrectcd. The resuits also show that the majcrity 
cL werk is being dcne in Record Processing and that the 
addition of a backend reduces’ the record rfrocessing time by 
nearly half. We discovered that it takes the backend twice 
as long tc process a message as it does the ccntrclier, 
Fossikly due to hardware processor speed. Finally, there 
exists a linear relationship between the message length and 
the time tc pass a message as the message length exceeds 100 


Eytes. 


C. RKECCMMENDATIONS FCR FUTURE EFFORTS 


Future improvements can be made in the performance reas— 
ucement methodology by the automation ot the existing 
external software tocls. Specifically, the ability to start 
a test which will execute a pre-determined set of reguests a 
pre-determined number of times for each reguest, and ccllect 
the results in a file is a desireable feature. 
Additional iy, Since the methodology is intended tc be 
general in use, tke methodology needs to be aprlied to 
different database systems tc discover its applicability, 
ease cf use, and usefulness in overall performance measure— 
ment cf the target systen. 

In terms of the application of this methodology to MDES, 
a ccuplete and thorcugh test of the system needs tc be 
conducted. An exhaustive test of MDBS would include 
conducting test with datakases that have varying treccerd 
sizes. Further, testing the system by varying the number of 


directory attributes, descripters, and clusters would indi— 
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mate the pele of the directcry data in the systen. fVcecre, 
delete, and update requests must also be measured to 
disccver their impact on system performance. mace iy, - che 
measurement should be extended to test MDBS when it uses the 


secondary—memory—based directory management process. 
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